Re: [Ejbca-develop] EJBCA is checking for serial number collisions after generating the certificate

[Tomas G. <to...@pr...>]

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 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?

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
>