What is the recommended way to add a new root certificate?

[Julian Davies]

Newbie here. We've got Coreos running in a VirtualBox VM. We are working behind a corporate firewall that decrypts https traffic and adds its own ssl certificate. 

When we try to download Docker images, we get "x509: certificate signed by unknown authority"

The only way we have found around this issue is to change the /etc/ssl/certs/ca-certificates.crt softlink to point to a new file /etc/ssl/certs/ca-certificates.crt.appended to which we have appended our corporate firewall root certificate. 

This seems to work but it also seems a bit wonky. We would rather append our certificate to the file the softlink was pointing to, which is /usr/share/ca-certificates/ca-certificates.crt. But that is read-only.

What is the right way of doing this?

cheers,

Julian

[Brian Harrington]

Julian,

Don't re-write the file ca-certificates.crt. Instead download the file to the directory /etc/ssl/certs/ then run "sudo c_rehash".

On any OpenSSL based system the trust model is based on the acknowledgement of the hash of a given certificate.  What the "c_rehash" script is doing is looking at the hash of a given certificate ("openssl x509 -noout -hash -in cername.crt") then explicitly creating a symbolic link in the form "hash".0 using the resulting value from the previous command.

So to talking this all out using CACert as an example (the short way):
$ sudo curl -o /etc/ssl/certs/cacert_root.crt http://www.cacert.org/certs/root.crt
$ sudo c_rehash

So to talking this all out using CACert as an example (the long way):
$ sudo curl -o /etc/ssl/certs/cacert_root.crt http://www.cacert.org/certs/root.crt
$ openssl x509 -noout -hash -in /etc/ssl/certs/cacert_root.crt
99d0fa06
$ sudo ln -s  /etc/ssl/certs/cacert_root.crt  /etc/ssl/certs/99d0fa06.0

Hope this helps.

--Brian 'redbeard' Harrington

--
You received this message because you are subscribed to the Google Groups "CoreOS User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coreos-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Marineau]

TL;DR; copy the cert to /etc/ssl/certs/foo.pem and call update-ca-certificates

On Fri, Aug 29, 2014 at 9:31 AM, Brian Harrington
<brian.ha...@coreos.com> wrote:
> Julian,
>
> Don't re-write the file ca-certificates.crt. Instead download the file to
> the directory /etc/ssl/certs/ then run "sudo c_rehash".
>
> On any OpenSSL based system the trust model is based on the acknowledgement
> of the hash of a given certificate. What the "c_rehash" script is doing is
> looking at the hash of a given certificate ("openssl x509 -noout -hash -in
> cername.crt") then explicitly creating a symbolic link in the form "hash".0
> using the resulting value from the previous command.
>
> So to talking this all out using CACert as an example (the short way):
> $ sudo curl -o /etc/ssl/certs/cacert_root.crt
> http://www.cacert.org/certs/root.crt
> $ sudo c_rehash

The file must end in .pem for c_rehash to use it. Also calling
c_rehash will only make the cert available to applications using
openssl with its default settings, applications written in go or that
specify a path to the certificate bundle file instead of the directory
will not pick it up. To handle both cases we provide the tool
"update-ca-certificates" which will do both.

>
> So to talking this all out using CACert as an example (the long way):
> $ sudo curl -o /etc/ssl/certs/cacert_root.crt
> http://www.cacert.org/certs/root.crt
> $ openssl x509 -noout -hash -in /etc/ssl/certs/cacert_root.crt
> 99d0fa06
> $ sudo ln -s /etc/ssl/certs/cacert_root.crt /etc/ssl/certs/99d0fa06.0

The manual procedure also needs:
$ sudo rm /etc/ssl/certs/ca-certificates.crt
$ sudo cp /usr/share/ca-certificates/ca-certificates.crt
/etc/ssl/certs/ca-certificates.crt
$ sudo sh -c "cat /etc/ssl/certs/foo.pem >> /etc/ssl/certs/ca-certificates.crt"

By default /etc/ssl/certs/ca-certificates.crt is a symlink to the copy
in /usr but you can replace that symlink with a regular file, from
then on the file will be automatically updated during boot so it
remains current after upgrades. Again, this does require that you name
your custom cert with the .pem suffix, otherwise on next boot it will
not be included when ca-certificates.crt is regenerated.

[Julian Davies]

Thank you very much! We followed the TL;DR; and it worked a treat. 

[Noah Lehmann-Haupt]

Ditto -- thanks for the heads-up on this.

I setup the following service in cloud-config to automate the process on system setup (elsewhere in the file I add our root certificate under write_files).

coreos:

  units:

    - name: updatecertificates.service

      command: start

      content: |

        [Unit]

        Description=Update the certificates w/ self-signed root CAs

        Before=etcd.service

        [Service]

        ExecStart=/usr/sbin/update-ca-certificates

        RemainAfterExit=yes

        Type=oneshot

[Brandon Philips]

On Fri, Aug 29, 2014 at 1:07 PM, Michael Marineau
<michael....@coreos.com> wrote:
> TL;DR; copy the cert to /etc/ssl/certs/foo.pem and call update-ca-certificates

I will write a quick doc so we don't have to keep this in tribal knowledge.

Mike- Is there a reason not to have a .path unit to run this automatically?

Brandon

[Michael Marineau]

rehashing certs during boot causes a significant delay, for a while we
used to do that but I stopped doing that in order to get boot to be
reasonably quick again.

[Brandon Philips]

On Tue, Sep 2, 2014 at 2:21 PM, Brandon Philips
<brandon...@coreos.com> wrote:

> I will write a quick doc so we don't have to keep this in tribal knowledge.

Doc is live: https://coreos.com/docs/cluster-management/setup/adding-certificate-authorities/

Thanks,

Brandon