About X.509 certificates serial numbers the RFC 5280 says:

The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer.

There is no mention of the security concerns with the serial number generation. What are the good practices? Is there any security issues with predictable (for instance sequential or based on the certificate generation date) serial numbers?

  • 1
    $\begingroup$ One of the OpenWISP modules has a django-app reusable app which implements x509 certificates with random serial numbers based on uuid4 integers. The code is open source (BSD): github.com/openwisp/django-x509 (the implementation was inspired by the discussion presented in this question) $\endgroup$ Commented Dec 11, 2017 at 14:10

2 Answers 2


A non-random serial number does not imply, by itself, a security issue with the signature scheme, but, as @Jack points out, it can be used to leverage an attack. On a general basis, signature algorithms begin by hashing the input message with a given hash function; if the message or hashing process is fully controlled by the attacker, then collision resistance of the hash function becomes an important issue. On the other hand, with some randomness inserted by the signer (e.g. a random serial number, added by the issuing CA of a certificate), the signature ought to be resistant to mere collision attacks, and, ultimately, work on preimage resistance (and MD5, with all its shortcomings, still appears to be optimally resistant to preimages).

Such randomness should be inserted in an "appropriate" way, which depends on the internal structure of the hash function. Halevi and Krawczyk have specified a generic way which should be good for all hash functions, and called it RMX. It has resulted in an Internet Draft and NIST Special Publication SP-800-106. Noteworthy points are:

  • RMX is meant to be applied on any binary message, but it requires generation of some random value, to be transmitted along with the message.
  • Since the hashing process is modified, the signer and verifier must be aware of RMX, right at the beginning of message processing.
  • RMX includes a description of how to extract the random value from the first half of a DSA/ECDSA signature (the "$r$" value, which does not depend on the signed message). This is meant to save bandwidth and be compatible with existing data formats (which do not have room for an extra "random value"), but it makes signature more complex, since the "$r$" value must then be generated before hashing the input message -- which can be cumbersome in systems where the hashing is externalized, in another module than the one holding the signature private key.
  • This is a recommendation which has not yet found its way in any notable standard.

Using a random serial number is the "poor man's randomized hashing" which has the fine property of being fully compatible with existing X.509 certificate verifiers (the hashing process and the certificate formats are not altered in any way) and many CA already implemented it, albeit not for protection against collision attacks. In a certificate, the serial number occurs "early enough" in the structure, with some big fixed elements between it and the public key (namely, subject and issuer names, validity dates...), so that it suffices, with existing MD-based hash functions (MD5, SHA-1...), to prevent leverage of collision attacks. Also, a long enough random serial number ensures uniqueness with overwhelming probability without having to look up anything in a database. For proper interoperability, use a positive serial number less than $2^{159}$ (this ensures that the value encoding, as specified in ASN.1 DER, will fit in 20 bytes).

Completely unrelated to collisions and signatures, but relevant for security, predictable serial numbers leak business information. As Peter Gutmann states it in his X.509 Style Guide (an old but fun and not completely obsolete text):

by using sequential numbers a CA ends up revealing just how few certs it's actually signing (at the cost of a cert per week, the competition can find out exactly how many certs are being issued each week)

  • $\begingroup$ If random serial numbers are used then what would be a good length for the serial numbers? Normally integers are 32-bits but in the case of X.509 / ASN.1 the sky is the limit. Heck - you have the integer type used for RSA keys with 2048-bit "integers". $\endgroup$
    – neubert
    Commented Jul 16, 2015 at 6:21
  • 2
    $\begingroup$ Integers are integers -- they are not bounded, otherwise we call them modular integers. It so happens that modern computers are most comfortable with integers modulo 32 or 64 bits (i.e. "32-bit or 64-bit integers") but they can still handle larger integers, as they do for RSA. For backward compatibility, X.509 (RFC 5280) says that the serial number shall be positive and its encoded value should fit in 20 bytes, which means that you have 159 bits to play with (serial number shall be between 0 and 2^159-1, inclusive). $\endgroup$ Commented Jul 16, 2015 at 12:27
  • $\begingroup$ Isn't the serial number public data/visible in certificate? if a random value is known does it increase security? $\endgroup$
    – yurtesen
    Commented Feb 29, 2020 at 19:44
  • 2
    $\begingroup$ @yurtesen The point of the random serial number is that it is not known by the person who requests the certificate prior to obtaining the certificate. Afterwards, the serial is public (since it is in the certificate) but at that point the signature has been produced by the CA and it's too late for the attacker to make a custom name+key that exercises a collision attack on the hash function. $\endgroup$ Commented Feb 29, 2020 at 20:25
  • $\begingroup$ @ThomasPornin is it too late for an attacker because the 'valid from' and 'valid to' fields will have different values and so the generated hash is harder to make identical? Or for other reasons? $\endgroup$
    – username
    Commented Nov 26, 2020 at 15:31

Predictable serial numbers were used (along with serious weaknesses in MD5) to create a rogue CA certificate in 2008. Randomizing the serial numbers would have prevented this attack.
And, obviously using a sequential serial number reveals the number of certificates signed, and requires careful state management.

In general I would say using a large (large enough that collisions are unlikely, say 128 or 160 bit) randomly generated number is best current practice, as otherwise all fields in the certificate are either known or predictable to an attacker, which may make it easier for weaknesses in the primitives (hashes or signing mechanisms) to be exploited, as it was with the MD5 attack.

  • 2
    $\begingroup$ What a magnificent article is referenced here... $\endgroup$
    – Artfaith
    Commented Feb 25, 2021 at 1:49
  • $\begingroup$ CABforum baseline requirements v1 in late 2011 recommended 20 bits, and 1.3.7 in 2016 required 64. These were and could be adopted only if voted by both CAs and browser makers. $\endgroup$ Commented May 20, 2021 at 2:21
  • $\begingroup$ The actual reason that they were able to create that certificate was that MD5 was used for the signature. Quote from the linked article: "It would be best to stop using MD5 for the creation of certificates altogether, as its continued use may lead to severe security problems. As a last resort, in the case that MD5 cannot be discontinued immediately, a CA can take simple alternative countermeasures such as randomizing the serial numbers of all newly issued certificates. We stress that such countermeasures are mere band-aids rather than fundamental solutions." $\endgroup$
    – Omikron
    Commented Apr 10, 2023 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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