How to get around Unrecognized Certificate Authority signature on Domino 9.0.1 with Go Daddy SSL?

Question

I am a part-time administrator, at best, so I only get to do these things once every 2-3 years.

I am reinstalling a Linux server that worked in 8.5.2. The SSL certificate is from GoDaddy. I have created the keyfile.kyr 1/2 dozen times without success. Following the instructions in the Domino Admin Help I

1. create the key ring
2. create a Request for "an SSL server certificate from the CA"
3. At the Go Daddy site I access my SSL certificates and use the "Re-Key" option to create the request with the SHA-2 signature algorithm and the Go Daddy issuing organization
4. Within a few minutes the download is available which I download. This download contains two files: gd_bundle-g2-g1.crtand 2b026decb857de.crt
5. Next I attempt to "Merge the CA certificate(s) as a trusted root into the server key ring file." from the gd_bundle-g2-g1.crt file. There are three certificates which have varying levels of success...

First certificate in the file is for the common name "Go Daddy Root Certificate Authority - G2". The attempt to merge it gets the result: "Certificate signature does not match contents"

The second certificate in the file is for the common name "Go Daddy Secure Certificate Authority - G2". The attempt to merge it gets the result: "Cannot find certificate issuer among trusted roots"

The third certificate in the file is for the common name "Go Daddy Root". The attempt to merge it succeeds.

Regardless of the order of these activities the errors persist on the first two.

When I attempt the next step of "Installing the certificate into the key ring" I get the message "Unrecognized Certificate Authority signature" which allows me to optionally merge the certificate anyhow. But using the certificate merged in this fashion results in the web site not being verified and the SSL lock is replaced by an exception exclamation point.

I have tried several of the other .crt files from Go Daddy available here: https://certs.godaddy.com/anonymous/repository.pki with no more success.

Thanks in advance for your ideas on this.

Solution 1

problem is that when you renewed the certificate, you accepted the default encryption method of SHA2 which is not supported properly yet. Needed to switch it to SHA1. SHA1 used to be the default but has recently changed. Something to be aware of going forward.

by default, godaddy now issues certificates in the higher new format. You can re-issue the cert at godaday and choose sha1.

Solution 2

First of all you need to dtermine the right order for importing. The root certificate is the first to import using the button "Install trusted root certificate...". I guess that the next one has to be the root -G2 and last but not least the Security one. After having installed all roots in the right order, you will then be able to install the certificate itself.

The reason for this is the following: Think of certificates as a chain. The rule to trust someone is the following: I only trust you, if I trust your father. The "root" certificate itself has no father (thats why it is called root). You import it first. With this root certificate another certificate is issued. To import the G2 you have to already trust its father.. And so on. The tricky thing is to find out "who issued what" and import in the right direction. After the chain is complete, you then can install the certificate itself.

Comments

[Newbs]

Yes, @Per Henrik, I used the "Install Trusted Root Certificate into Key Ring"option for the three certs in gd_bundle-g2-g1.crt and others I tried from the repository.

[Newbs]

I have tried all possible order of these things without success. As I stated: "Regardless of the order of these activities the errors persist on the first two."

[Newbs]

That makes sense, retrying with the SHA1 method...

[Newbs]

I got the keyfile.kyr rebuilt using the SHA1 method and the merge all worked (no error messages)! But after restarting the server (both the HTTP task and then the whole server) it still indicates that it is not verified as an SSL host. Any ideas?

[Newbs]

Turns out the indication of not being verified was due to an image being accessed from somewhere else not using SSL. Once I fixed that link all is good. Thanks for your help.