![]() ![]() $ cat server.crt subordinate-ca.crt signing-ca.crt > server.pemīut verification fails. It is mentioned to create chain bundle, the lowest should go first. root-ca => signing-ca => subordinate-ca => server The certificates in cacerts are periodically updated as various certificate authorities update their public trust certificates, so you will need to maintain this file over time.ĭepending on which browser you are using you may need to install the certificate as a trusted certificate into the browser's keystore which may not be either of the stores already discussed.I've created a chain hierarchy like this. The simplest and most stable option would be to install the file in the default Java version. This may be a sub-set of the default set. ![]() With either file, you need to ensure the file contains all the certificates you want to trust. Alternatively, you may be able to install a jssecacerts file next to the existing cacerts file. You will need to either install a new cacerts file or import the certificate into the cacerts file. Java uses a cacerts file located within the installation directory. I found this simpler to define than running a program when the certificate was installed. When deploying certificates using cfengine, I include a step to add the symbolic link after the certificate is copied. Tools like update-ca-certificates ensure that the certificate is linked to by a symbolic link that matches the hash value of the certificate. I'm not aware of other things on linux that use an alternative certificate store, besides perhaps Wine running an Adobe Air app. If they don't output useful info at all, then you need to check your cert and make sure it's in valid PEM format.ĮDIT: BillThor mentioned this won't work for Java, but it appears as though on debian at least, Java's certificate store is also kept up to date by the update-ca-certificates tool. If they don't match, then you should re-run update-ca-certificates -fresh You should see some extensive info about your certificate, and both should match (since with a symlink they should be the same file). Openssl x509 -in /usr/local/share/ca-certificates/.pem -noout -text Openssl x509 -in /etc/ssl/certs/.pem -noout -text You can test your certificate installation by running openssl against the cert: ![]() IR9NmXmd4c8nnxCbHIgNsIpkQTG4DmyQJKSbXHGPurt+HBvbaoAPIbzp26a3QPSy GjELMAkGA1UEBhMCVVMxHjAcBgNVBAsTFXd3dy54cmFtcHNlY3VyaXR5LmNvbTEk MIIEMDCCAxigAwIBAgIQUJRs7Bjq1ZxN1ZfvdY+grTANBgkqhkiG9w0BAQUFADCB pem format file looks like this: -BEGIN CERTIFICATE. ![]() Lrwxrwxrwx 1 root root 61 Sonera_Class_1_Root_CA.pem -> /usr/share/ca-certificates/mozilla/Sonera_Class_1_Root_CA.crtĪlso notice that *.crt and *.pem are the same file. Lrwxrwxrwx 1 root root 69 Security_Communication_Root_CA.pem -> /usr/share/ca-certificates/mozilla/Security_Communication_Root_CA.crt Lrwxrwxrwx 1 root root 69 Security_Communication_RootCA2.pem -> /usr/share/ca-certificates/mozilla/Security_Communication_RootCA2.crt Lrwxrwxrwx 1 root root 72 Security_Communication_EV_RootCA1.pem -> /usr/share/ca-certificates/mozilla/Security_Communication_EV_RootCA1.crt As BillThor mentioned, there will also be a symlink to a file with the fingerprint as a name - it will be similar to 349f2832.0. # -fresh is needed to remove symlinks to no-longer-present certificatesĪlso, note that once update-ca-certificates is complete, it should have symlinked the /etc/ssl/certs/*.pem files to their respective certificates in /usr/local/share/ca-certificates/ or /usr/share/ca-certificates/. rm -f /usr/local/share/ca-certificates/certificate.crt I agree with everything BillThor mentioned, but i'll add that it may be necessary to completely rebuild the certificate store, because sometimes it seems like update-ca-certificates tries too hard to be lazy, and doesn't actually update things it should. Is there a way to script Ubuntu to non-interactively update the trusted CA certs in a manner that could work against thousands of machines? We use CFEngine for configuration management, but it does not seem to have a facility for this sort of thing as far as I can tell. Not only have these commands not worked, it would be impractical to run them against thousands of servers. According to another post, we need to run dpkg-reconfigure -f noninteractive ca-certificates or update-ca-certificates on each machine that has the cert. Once this was done however, applications on the Ubuntu machines such as wget/curl/java still do not trust connections that use the new certs. After creating a new certificate authority, manually importing the CA chain to a browser, and verifying that browsers can trust new certs signed with the intermediary, we copied the CA cert chain (pem and crt formatted) to our Ubuntu servers under the following directories: ![]()
0 Comments
Leave a Reply. |