2

(FYI: I'm using Ubuntu 18.04 Desktop although I don't think my question is platform-dependent.)

I read the article Scalable and secure access with SSH and it says:

... if you want to use revocation lists, unique serial numbers are a requirement.

But by reading ssh-keygen manual page, I didn't seem to find a way to guarantee the uniqueness of the serial numbers. It looks to me it's completely managed by the CA, i.e., the CA needs to figure out a way (either their own database or just a spreadsheet) to manage the serial numbers. I'm wondering if my understanding is correct or not.

My second question is: Why is it required to use unique serial numbers for revocation? I'm asking because the section "KEY REVOCATION LISTS" of ssh-keygen manual page says:

A KRL specification consists of lines containing ONE OF the following directives followed by a colon and some directive-specific information.

Then the manpage lists the directives that can be used:

  • serial: serial_number[-serial_number]
  • id: key_id
  • key: public_key
  • sha1: public_key

The words sound like that, if serial numbers are not unique, CA can still use other directives to revoke the certificates. The manual page says "ONE OF", not "ALL OF".

Improve this question

2 Answers 2

Reset to default
1

The article is simply wrong, serial numbers are not required in order to use revocation lists, but there are some cases where having a serial number would make the revocation process easier to manage.

One example of this is in the case where a user certificate was signed with a set of restricted options and now you want to re-sign it with a different set of options. If you are not using serial numbers then for this to work you have to have the user generate a new key that you can sign with the new options, because without a serial number you can revoke based on the key, but that invalidates all certificates ever created from that key. If you are using serial numbers you can revoke only specific certificates from that key and allow the newer ones to continue to be valid.

As far as ensuring uniqueness, since the serial number is a 64-bit integer I find the easiest solution is simply to use the current epoch time (perhaps in milliseconds if you feel you might someday need to issue more than one certificate per second).

Improve this answer
2
  • An easy way to generate uniqueness is to add -z $(date -u "+%Y%m%d%H%M%S") to your ssh-keygen command. This will make the serial number the current timestamp. As long as you are not generating many keys per second, you should be fine with this.
    – MERM
    Commented Sep 15, 2023 at 22:40
  • -z $(date +%s%N | cut -b1-13) gives the milliseconds
    – k_o_
    Commented May 2 at 12:37
0

My testing showed that the serial numbers seem to be used to uniquely identify the certificates that are revoked. Therefore, if two certificates are using the same serial numbers, revoking one will cause the other to be "revoked", too, so the other certificate won't be able to authenticate the user.

Therefore, it's true that the serial numbers of certificates should be unique.

I haven't found a way to automatically guarantee the uniqueness of the serial numbers. Therefore, for manual management, a spreadsheet might be needed. When the certificates are generated automatically by some program, the program may simply increment the serial number by 1. The serial number in openssh is implemented as an unsigned 64-bit integer so it should be extremely unlikely to consume all of them.

UPDATE: I wrote an article with more details: SSH: Uniqueness of X509 Certificates Serial Numbers

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .