Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've set up a small PKI using the openssl ca, by following a guide which explains the procedure and some of the concepts in good detail. I want to accomplish pretty much that three-tiered setup that is outlined in that article, namely that the actual certificates are issued by an Intermediate CA which is in turn 'governed' by a Root CA, with the Root CA being self-signed and eventually deployed to the clients concerned. I have tried to reproduce the configuration in the article as close as possible, to prevent that I customise too many things at once which I don't understand yet.

So far, I have the following:

  • The certificate and 'infrastructure' for the root CA.
  • The certificate and 'infrastructure' for the intermediate CA.
  • The CRLs for both CAs.
  • A test certificate, issued by the intermediate CA, to check whether all of this works.
  • Copies of the Demo CA for comparison.

In theory, by deploying the root CA's certificate to a browser and then browing to the website secured by that last certificate, I should get 'the padlock icon'. This does work with Internet Explorer, Chrome and Firefox. Opera is acting up and bails with 'Secure connection: fatal error (1578)', so something is obviously broken.

A forum article suggests that the problem lies in the CRLs, so I went to investigate there. Internet Explorer has no problems in opening the CRLs and displays them correctly, without any notice that there is something wrong. Firefox on the other hand refuses and gives 'Error code ffffe00a', which indicates problems with the signature (Error -8182: SEC_ERROR_BAD_SIGNATURE: Peer's certificate has an invalid signature.). This however only happens only when I did import the CA certificate first. If I don't, then the CRL is accepted without problems.

I have verified all the certificates and CRLs with whichever invocations of both openssl and Microsoft's certutil.exe that I could get my hand on, all of which giving me the thumbs up.

Putting my certificates side to side next to the demo certificates in the abovementioned article I don't see difference—other than the names, of course. So in theory they should behave the same. But trying to import the root certificate of the Demo CA and then looking at the CRL works, in all browsers, whereas my own Root CA leads to those weird errors. (Lacking the private keys of the Demo CA, I can of course not test whether certificates issued by the Demo CA would work.)

I am stymied. I seem to be missing something subtle, but important, but I am out of ideas and resources. Thank you for any suggestions or pointers.

share|improve this question

migrated from security.stackexchange.com Dec 10 '12 at 15:30

This question came from our site for Information security professionals.

2 Answers 2

If the certificate is set up properly from a CA perspective, perhaps the web server or the browser isn't building the chain correctly.

Make sure the web server has the root and intermediate certificate installed correctly, and in particular some servers (or load balancers) need to have the chain "linked" using a application specific command.

Alternatively, know that each browser IE and Firefox (not sure about Chrome) maintains its own CA trust store. You will have to install the root and perhaps thex CA into that respective store.

Another tool that you may want to use to compare certificates is the ASN.1 inspector, available here ( http://www.lapo.it/asn1js/ )

share|improve this answer
    
The webserver seems to build the chain correctly. If I prime curl with my root certificate, then doing curl -vI https://www.aleturo.com/ tells me SSL certificate verify ok. Only Opera is acting up, but from what I've read I gather that Opera is the most strict when it comes to SSL stuff, so something is still off. Dissecting the certificates with an ASN.1 parser is something which I didn't think of yet, I'll look into it. –  Vucar Timnärakrul Dec 9 '12 at 14:04
up vote 0 down vote accepted

Turns out the problem was simply a caching issue. Re-creating all CAs and certificates from scratch (just to be on the safe side), and most importantly: clearing the browser cache of all browsers did the trick.

In a way, the various hints towards CRL problems turned out to be the root cause. Since the CRL is supposed to be cached (and especially for the Root CA has a rather long lifetime), it actually was cached. Since I've been trying to build the PKI, I've been scratching and re-creating the various CAs, CRLs and whatnot several times over. When I was doing the final tests, the browsers had the newest CA certificates, but were still trying to match them with the old CRLs still in the browser cache (the URL of the CRL didn't change). Of course, they didn't match and both Opera and Firefox—correctly—complained.

After flushing the browser caches and re-deploying the root certificate I finally noticed in the web server logs that Opera requested the CRLs for both the root and the intermediate CAs—something which I didn't see before (as they were still cached). And from then on, everything was fine. I was able to install the Root CA and nobody is complaining anymore.

Now the real work begins…

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.