Menu
▾
▴
Re: [Ejbca-develop] EJBCA is checking for serial number collisions after generating the certificate
|
From: Jaime H. <hab...@gm...> - 2019-03-12 14:51:53
|
On Tue, Mar 12, 2019 at 7:58 AM Tomas Gustavsson <to...@pr...> wrote: > > Now you are getting into semantics. I believe you read the code correct. > The definition used by me is a difference between "internally generated" > and "issued by the CA". > > The code is there to guard against any certificate with duplicate serial > numbers being "issued from the CA". This is done by verifying, after the > certificate has been created in memory, but before it is stored > anywhere, or returned to anything outside the internal RAM But the colliding precertificate is still published outside to the CT Logs, which could lead to the following scenario: 1. A certificate is issued for a subject X with a random serial number A and it is appropriately stored and published to CT Logs. 2. A new certificate for subject Y is about to be generated and the random serial number generation process generates the same serial number A (very unlikely but not impossible). 3. A precertificate for the new certificate is signed and published to CT Logs. 4. The final certificate is signed but never stored in system because of the check made by org.cesecore.certificates.certificate.CertificateCreateSessionBean#assertSerialNumberForIssuerOk . And now there are two different precertificates with the same serial number published into CT Logs which is to be considered a misissuance as indicated in RFC 6962, "3.1. Log Entries": The signature on the [precertificate] TBSCertificate indicates the > certificate authority’s intent to issue a certificate. This intent > is considered binding (i.e., > *misissuance of the Precertificate isconsidered equal to misissuance of > the final certificate*). And additionally, revoking the misissued precertificate will revoke the previously issued correct certificate. Note: I haven't verified if CT Logs would accept two different precertificates with the same serial number, but I think they will. > of the > running process, that there are no issuer/serialnumber collisions. There > are other similar guards available as well, such as applying a unique > database index preventing storage of certificates with duplicate > issuer/serial. > > And of course, the most effective guard is to use serial numbers with > sufficient length, making the probability of collisions unlikely to > happen anytime at all. > > The code does what what it was designed to do. Do you see any issues > with the code? > I think that the call to verify if the newly generated serial number is about to collide with an existing one should be performed early, before any signature is generated in the pre-certificate or the real certificate. > > Do you use short serial numbers? > I do not recommend that you use shorter serial numbers than 64 bits, > unless you have a very special use-case. > > Regards, > Tomas > > PS2: In EJBCA 7.1.0 a new validation step will be added giving the > possibility of running validation of a pre-sign-certificate, which is > signed by a dummy key, before the CT pre-certificate is created. The > purpose is not to look for or prevent collisions though, but can be used > for other validation before anything CT related is generated. > > > On 2019-03-12 13:19, Jaime Hablutzel wrote: > > On Tue, Mar 12, 2019, 3:53 AM Tomas Gustavsson <to...@pr... > > <mailto:to...@pr...>> wrote: > > > > Hi Jaime, > > > > Good point about CT pre-certs. With "no certificates" we mean the > final > > certificate. > > > > > > The final collisioning certificate is generated too. Take a look at the > > source code before the call > > > to org.cesecore.certificates.certificate.CertificateCreateSessionBean#assertSerialNumberForIssuerOk. > > > > The CT pre-certificate is by definition not a > > "certificate", it's a "pre-certificate" and can by construct (poison > > extension) not be used as a certificate. > > > > Of course, the issuance of a pre-certificate has it's own > consequences > > such as having to revoke it. > > Though, as you know, CT is only used for public trust issued > > certificates, and there it is not allowed to use 32 bit serial > numbers. > > In fact more than 64 bit serial numbers are needed. This makes this > > discussion mostly academic. > > > > Regards, > > Tomas > > > > > > On 2019-03-11 16:37, Jaime Hablutzel wrote: > > > Quoting > > > > > from > https://groups.google.com/d/msg/mozilla.dev.security.policy/nnLVNfqgz7g/OVKywVZIBgAJ > : > > > > > > In addition to random serial numbers, EJBCA checks for > collisions, > > > so even in the very unlikely event of equal serial numbers > being > > > generated, *no certificates with duplicated serial numbers > > should be > > > issued from a CA based on the EJBCA software*. By comparison, > > > collisions do happen regularly in testing when using 32 bit > serial > > > numbers (and are averted), so the underlying checks function > as we > > > expect. > > > > > > > > > Where the highlighted text is not correct, because, as observed > > from the > > > trunk source around r31776, if a newly generated random serial > number > > > (generated by > > > org.cesecore.certificates.ca > > <http://org.cesecore.certificates.ca > >.internal.SernoGeneratorRandom#getSerno) > > > results that is being used by an existing certificate, a new > > > collisioning certificate is still generated (and CT precertificate > > > published!) but it is discarded only before trying to store it in > the > > > database, when the collision validation is performed > > > > > > (org.cesecore.certificates.certificate.CertificateCreateSessionBean#assertSerialNumberForIssuerOk). > > > > > > It isn't the expected behaviour. Isn't it?. > > > > > > -- > > > Jaime Hablutzel - RPC 994690880 > > > > > > > > > _______________________________________________ > > > Ejbca-develop mailing list > > > Ejb...@li... > > <mailto:Ejb...@li...> > > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > > > > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > > <mailto:Ejb...@li...> > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > > > > _______________________________________________ > > Ejbca-develop mailing list > > Ejb...@li... > > https://lists.sourceforge.net/lists/listinfo/ejbca-develop > > > > > _______________________________________________ > Ejbca-develop mailing list > Ejb...@li... > https://lists.sourceforge.net/lists/listinfo/ejbca-develop -- Jaime Hablutzel - RPC 994690880 |
