I have tried to issue a certificate beginning with 8 to F but I have found it is impossible, mostly due to the RFC:

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.

So I would like to know if there is any actual reason not to do that beyond the "buggy ASN.1 implementation"?


Short answer: because RFC 3280, its predecessor, says so.

Longer answer: because historically ASN.1 encoders/decoders have had problems with properly encoding and decoding integers.

X.509 uses DER encoded ASN.1, which amongst other things, means that the data must be encoded in its minimal (shortest) form. As integers are stored in a variable length twos-complement form, in order to properly encode a non-negative integer which happens to have its leading bit (MSB) set, it must be padded with a leading zero, which in other circumstance is disallowed. The wording of X.690(http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf‎ ) is such that the leading 9 bits of an integer must be inspected in order to verify the minimal form, thus allowing such positive integers to have leading 0 byte.

To quote Peter Gutmann

There's a second but: Historically many encoders have gotten the signedness of integers wrong, which means that (a) if you get a negative number (at least in the area of crypto, which I'm most familiar with) it's always an encoding error and never a deliberate use of a negative value, and (b) because of the widespread use of incorrect encoders, many decoders treat all integer values as unsigned. So while you can use negative values in theory, it's not a good idea in practice.

The correct determination of serial numbers is critical when it comes to revocation checks. Ambiguity is an enemy.

It seems to me that this is exactly the problem your encoder is having...

| improve this answer | |
  • It is really surprising something to become standarized mostly due to implementation faults. Thanks for your response. – kiBytes Feb 19 '14 at 7:06

ASN.1 defines the serialNumber OID of to be a PrintableString. It is not defined as a numeric attribute, therefore any printable characters are permitted, and no sign is required or even interpreted.


serialNumber ATTRIBUTE ::= {
  WITH SYNTAX               PrintableString(SIZE (1..MAX))
  SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
  LDAP-SYNTAX               printableString.&id
  LDAP-NAME                 {"serialNumber"}
  ID                        id-at-serialNumber

However, RFC 2459 defines CertificateSerialNumber to be an INTEGER.


It qualifies serial numbers this way:  Serial number

The serial number is an 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

So the restriction comes from the RFCs, not from ASN.1

| improve this answer | |

Because a serial number is designed to be a non-negative incrementing number.

It's basically an inventory control code for a CA, and they are non-negative incrementing numbers in most inventory systems.

| improve this answer | |
  • This makes little to no sense. The current standard practice is to use a randomly generated value for the serialNumber in an X.509 certificate. – Adi Feb 18 '14 at 18:24
  • 3
    Current standard practice is unrelated to what it was designed for. – Stephen Touset Feb 18 '14 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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