The CRL identifies certificates by serial number only; the issuer is implied. You cannot have a CRL that revokes certificates from more than one issuing certificate. The only parameter from a certificate to determine if it is revoked is the serial number. However, it's important to note that a certificate can only be revoked by a CRL that has the same issuer. Two certificates issued by different CAs can have the same serial number. A CRL from CA1 can only revoke the certificate from CA1; it cannot revoke a certificate from CA2, even if both certificates have the same serial number.
Given that you're controlling the CA, I suppose the method you list below could work, but you'll also need to remove the original certificate from the .index file and from the .certs directory that OpenSSL creates to manage the CA. Failure to do that will result in OpenSSL giving an error message. If the goal is to have a CRL whose lastUpdate is before the notBefore parameter on one of the certificates it revokes, I would recommend instead to set the clock backwards, and then generate a new CRL. I would be surprised if OpenSSL checks the current date against the dates on the certificate(s) that are revoked. > -----Original Message----- > From: [email protected] [mailto:owner-openssl- > [email protected]] On Behalf Of Al > Sent: Wednesday, November 18, 2009 9:12 AM > To: [email protected] > Cc: [email protected] > Subject: RE: how to create an already revoked certificate? > > Thanks for the reply, > I have control of the CA in creating certificates. The CRL contains > the SN of the certs that are revoked. I also noticed we have an SRL > file which shows the last SN used for the certificates and it > increments by 1 for every certificate created. You said: > "Having the same serial on CA2 as on CA1 is totally irrelevant." > Does that mean the CRL goes by more than the SN? I was thinking of > doing this: > edit the SRL and replace it with the SN of the revoked cert, after > using it i revert back to the correct SN pattern. > > If the CRL does need to have a perfect match to treat the created cert > as a "revoked cert" do i need to create a perfect replication in terms > of all input parameters or the CRL will be smart enough to know they > are still different? > > thanks > > > > --- On Tue, 11/17/09, Dave Thompson > <[email protected]> wrote: > > > From: Dave Thompson <[email protected]> > > Subject: RE: how to create an already revoked certificate? > > To: [email protected] > > Date: Tuesday, November 17, 2009, 4:06 PM > > > From: [email protected] > > On Behalf Of Al > > > Sent: Monday, 16 November, 2009 15:40 > > > > > I am trying to create a certificate that is already > > revoked > > > (for testing purposes). I noticed the CRL has the SNs > > of the > > > certificates and i am wondering if i could set the SN > > to > > > > Yes, certs are identified for many purposes, including > > revocation on a CRL, by serial within CA. > > > > > revoked cert SNs during new certificate creation? > > > > > This is not entirely clear; I assume you mean create a new > > cert > > with a serial that is already on a CRL issued by the (same) > > CA. > > (You can't change the serial on an issued cert; it's part > > of the > > signed content. You legally could create/issue a new cert, > > > > with new CA/serial, and all other contents the same as an > > existing cert, even validity. But it's usual to redo the > > validity. > > Having the same serial on CA2 as on CA1 is totally > > irrelevant.) > > > > If you control the CA, maybe; it depends on what the CA > > software > > does. A CA is not SUPPOSED to ever issue different certs > > with > > the same serial, but you may be able to override or fake > > yours. > > openssl ca|x509(ca)depend on text files you can clobber; > > openssl req(self)|x509(self) obey the command line. > > > > If you do create two (or more) certs with the same serial, > > and > > both (or multiple) of them are ever present in any > > environment, > > you have a very good chance of creating chaos. The purpose > > of > > the serial is to uniquely identify the cert within a given > > CA, > > and lots of software assumes this. If there are two > > different > > certs with the same serial for the same CA, all kinds of > > things > > can go wrong that you can spend months debugging. > > > > But if you control the CA, you should be able to easily > > issue > > a new CRL about as easily as you can issue a new cert. > > > > If you don't control the CA, and it is competently run, no. > > It > > will always create new certs with unique serials, as it > > should. > > > > > > > > > ______________________________________________________________________ > > OpenSSL Project > > > > http://www.openssl.org > > Development Mailing List > > [email protected] > > Automated List Manager > > > > [email protected] > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [email protected] > Automated List Manager [email protected]
smime.p7s
Description: S/MIME cryptographic signature
