"Nelson Bolyard" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Jim, a.k.a. Ohaya, wrote: > > > I have a somewhat generic question regarding verifying CRL signature, > > which is not specifically wrt Netscape or Mozilla, but it is crypto > > related, so I was hoping that someone here could provide some > > guidance... My apologies in advance, as I know that this is > > off-topic... > > > > My understanding is that CRLs are signed by the CA. > > They're signed by SOME ca. In the simplest model, the same CA that > issues the certs issues the CRL for those certs. But the PKI standards > permit a CA to delegate the CRL issuance task to another CA. The certs > tell the verifier where/how to get the relevant CRL (or OCSP). The CRL > itself names its own issuer. The signature on the CRL is checked using > its issuer's cert, just as the signatures on the EE certs are checked > using their respective issuers' certs. > > > In our case, we have a 2-level CA hierarchy, with a root CA, and a > > sub-root CA. The sub-root CA is issuing both client and server certs, > > and thus the sub-root CA also produces a CRL. > > > > I'm assuming that in the above scenario, the sub-root CA, and not the > > root CA, signs the CRL with its private key. I believe that this is > > correct. > > Your setup sounds like *one* of the correct ways of doing it. There are > lots of details to get right, such as the cert extensions that tell the > verifier where to find the CRL, without which the verifier might not even > be checking the CRL at all. > > > Now, our server is using the CRL from the sub-root CA for checking for > > client certificate revocation. But, in order to check the signature of > > the CRL from the sub-root CA, doesn't the server need the sub-root CA's > > certificate? > > In order to check the signature on the CRL, the verifier needs the cert of > the CRL's issuer, who may or may not be the same as the CA that issued the > certs whose revocation is being checked. > > > The reason that I'm asking this is that I did an experiment: > > > > 1) Originally, I had the CRL and the certs from both the root CA and the > > sub-root CA installed on our server, which is configured for both client > > and server authentication, and everything was working fine. > > > > 2) I then removed the sub-root CA cert completely from the server. > > This, I thought, would break the chain of trust, and more specifically, > > would cause the server to no longer be able to use the CRL, since it > > couldn't check the CRL signature. > > > > 3) I was kind of surprised that even after removing the sub-root CA cert > > from the server, everything still seemed to be working, including the > > server checking the revocation status of client certs. > > Let's assume for the sake of this discussion that you did indeed remove > the CA cert that is needed to verify the CRL's signature from a running > server's permament store of certificates (as opposed to from its in memory > store of certs, whose contents change with each new incoming SSL client > authentication), without restarting that server. The server has probably > already checked the signature on the CRL once, and remembered that result. > The server need not check the signature on the CRL over and over. So, the > server can remember that the CRL is valid even after the CRL's issuer CA > cert is removed. > > If the authenticating SSL clients are following the SSL3 orTLS standards > they will send in not only their EE certs, but also the cert chain for > their EE certs, including the issuer of their EE cert. So, at the time > that the server goes to validate the client's cert and cert chain, it > probably has a copy of the CA cert that issued the client's EE cert, > which just happens to be the same CA cert that issued the CRL. So, the > cert is available for whatever needed purposes for the course of the EE > cert verification. > > > I guess that "where I am" is that I'm coming close to the conclusion > > that the server is not checking the CRL signature, > > I wouldn't guess that. > > > but I keep wondering > > if there may some other possible way that the server could be getting > > the public key of the sub-root CA for doing CRL signature checking? > > > > I hope that someone might be able to clarify this... > > If the CRL's issuer was NOT also the EE certs' issuer, and you removed > the CRL issuer's cert, AND you restarted the server process, so that it > could not have a previous copy still in memory, and it STILL worked, > then I'd say something's fishy. But as long as the server has access > to the CRL issuer's cert (e.g. because the clients are sending it in), > and as long as it is possible that the CRL's signature was validated > before you removed the issuer's cert, then I don't think you can conclude > that the CRL's signature is going unchecked. > > /Nelson >
Nelson and Julien, Thank you very much for your responses. I want to apologize again for this being perhaps off-topic here, but there are just so few places nowadays for getting info about the "inner" workings of SSL and PKI, so I really appreciate your knowledge here, and thank you for your help. In my original post, I forgot to mention that I did check the key id in the CRL, and it is indicating that the CRL was signed by the sub-root CA (and not by the root CA). But I've done some further testing, and based on that, I now think that Nelson is correct, and that the server must somehow (probably via the cert chain sent by clients) have access to the sub-root CA's certificate to do the CRL signature verification. Here's what I did: 1) I have a working, valid, signed CRL file that has client certs A and B listed as revoked. I have these 2 client certs, plus one other one (C). 2) I used a hex editor (XVI32) to edit the CRL. I found the serial number for cert A, and changed that serial number in the CRL to something else. The signature of this edited CRL should now be bad. 3) I then imported the edited CRL into the server's certificate store, and connected to the server using certs A, B, and C. The result was that the server responded with a 403.13 (revoked) error on all 3 connections. 4) I then went back and edited the edited CRL back by changing the serial number listed back to the serial number for cert A. 5) I then imported the re-edited CRL into the server's certificate store, and connected to the server using certs A, B, and C. The result was that the server responded with a 403.13 error for certs A and B, and allowed connection with cert C. Based on the above test, it appears that: 1) The program I'm using to import the CRL into the server certificate store is not checking the CRL signature, and 2) The server is checking the CRL signature, and if that check fails, it is considering all client certificates revoked. I think that security-wise, #2 above is a "good thing", and I can live with #1. Again, thank you for your patience in responding to my off-topic post, and any thoughts you might have would be appreciated! Yours, Jim _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
