I am having a strange problem. I have installed a new certificate from RapidSSL onto Apache on an Ubuntu server for the website http://www.radflek.com/shop/.

It seems to work absolutely fine on all PC browsers I try, but when I try on iPhone or iPad I receive the error: "Safari cannot open the page because it could not establish a secure connection to the server.".

Can anyone advise as to what might be wrong?!

UPDATE: I was unable to solve this issue, but when iOS 5.1 was released this issue resolved itself entirely so it appears to be related to iOS5.0 only.

It's been reported that some GeoTrust CAs are not in Safari's keychain. This may be the case for you; does Safari report that the certificate is not trusted because it is not issued by a trusted authority or because it can not be verified?
– Chris SFeb 4 '12 at 19:18

That is the whole error message... not much to go on
– faroligoFeb 4 '12 at 19:21

Have you tried Safari browser for Windows? If it will have the same behaviour as on iPhone, then @ChrisS is correct.
– LazyOneFeb 4 '12 at 19:36

Haven't tried Safari for Windows but on Safari for OSX it works fine
– faroligoFeb 5 '12 at 2:15

3 Answers
3

They gave you an incomplete certificate chain; mobile browsers tend to be a little more sensitive to chain issues than others. The intermediate issuer certificate with a thumbprint of c039a3269ee4b8e82d00c53fa797b5a19e836f47 is being presented correctly, but the "root" certificate that your server is presenting isn't a root certificate at all; it's an intermediate.

The real root cert (de28f4a4ffe5b92fa3c503d1a349a7f9962a8212, which most browsers will figure out), and the presented root-that-isn't (7359755c6df9a0abc3060bce369564c8ec4542a3) share the same cryptographic key, so their signing relationship with the issuing CA works either way - but the presented root's not a root at all, its trust chain relies on a root certificate (d23209ad23d314232174e40d7f9d62139786633a) that isn't being sent.

Either they gave you a certificate bundle to point to with an SSLCertificateChainFile directive, or rolled the roots into the public key file that's pointed at with SSLCertificateFile - figure out which, then you'll be modifying that file.

Copy the file as a backup before modifying it. Then, find this section:

Thanks so much for taking the time to have a look. I tried options A and B but the same issue seems to be occurring. I have left you option A in place, do you think you might be able to have another look?
– faroligoFeb 5 '12 at 2:15

@faroligo Looks like I'm seeing option B from the site at the moment - is that intended? Hmm, definitely still broken with that though - and either option ought to work because both CAs are in the list of iOS trusted roots. Something else is amiss - Do you have a manually defined SSLCipherSuite directive? What's in it, if so?
– Shane Madden♦Feb 5 '12 at 4:39

you are right, I had left option B in place, have now switched to option A again. You can see the chian file: gist.github.com/5ba269759df9a318deb7 I do not currently have a manually defined SSLCipherSuite, I previously tried with SSLCipherSuite !NULL:!ADH:!EXP:!LOW:SSLv3:+HIGH:+MEDIUM but that didn't seem to make a different. I have included the apache conf for the SSL site here: gist.github.com/d7c60d9a37e21021b758
– faroligoFeb 5 '12 at 11:21

Nothing in that config looks amiss to me.. is there anything else touching port 443 at all? What do you get from apache2ctl -S? And this this a long shot, but I'm guessing there's nothing useful in the error log?
– Shane Madden♦Feb 6 '12 at 16:52

A certificate can contain a special Authority Information Access extension (RFC-3280) with URL to issuer's certificate. Most browsers can use the AIA extension to download missing intermediate certificate to complete the certificate chain. But some clients (mobile browsers, OpenSSL) don't support this extension, so they report such certificate as untrusted.

You can solve the incomplete certificate chain issue manually by concatenating all certificates from the certificate to the trusted root certificate (exclusive, in this order), to prevent such issues. Note, the trusted root certificate should not be there, as it is already included in the system’s root certificate store.

You should be able to fetch intermediate certificates from the issuer and concat them together by yourself. I have written a script to automate the procedure, it loops over the AIA extension to produce output of correctly chained certificates. https://github.com/zakjan/cert-chain-resolver