https://www.ietf.org/rfc/rfc5280.txt
4.1.2.2. Serial Number
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.
Given the uniqueness requirements above, serial numbers can be
expected to contain long integers. Certificate users MUST be able to
handle serialNumber values up to 20 octets. Conforming CAs MUST NOT
use serialNumber values longer than 20 octets.
Note: Non-conforming CAs may issue certificates with serial numbers
that are negative or zero. Certificate users SHOULD be prepared to
gracefully handle such certificates.
On 9/17/2019 1:26 AM, Jakob Schürz wrote:
Thank you for your answer.
Am 17.09.19 um 02:02 schrieb Damien Miller:
On Mon, 16 Sep 2019, Jakob Schürz wrote:
Hi Daminan!
Hmmm... thought about a little...
when i use -vvv with ssh-keygen -Qf i see "debug1:..." So i think, debug
is compiled in.
debugging is compiled in generally, but the the recipe I mentioned turns
on extra KRL debugging.
I think, it's not necessary now.
ssh-keygen --help gives me
ssh-keygen -k -f krl_file [-u] [-s ca_public] [-z version_number] file ...
so... option -z is not the serial of the certificate, it is the
version-number of the KRL-File...
oops, yes.
This means, with -z i can give my KRL-File a serial-number? How can i
dump the revoke-file infos?
My openssh-Verision from Debian is 1:7.4p1-10+deb9u7. Maybe, this
openssh-version does not support revoking a certificate by it's
serialnumber.
It almost certainly does, but you'd need to use a KRL specification file.
See the "KEY REVOCATION LISTS" section in the ssh-keygen manpage.
This section is not clear enough. Please add some examples.
This leads me to the next question... The serial-number of
a certificate is uniq over all certificates, or is it allowed, to
increment serial-numbers for each certificate separate? How is the design?
what goes in the serial number is totally up to the CA. OpenSSH doesn't
make any authentication decisions based on it - it's in the certificate
mostly to allow very compact revocation lists.
I played around a little. I have a bunch of different certificates
(different users, rsa, ecdsa, ed25519-keys...). Some with the same
serial-number, some with different. I set up my CA to increment each
certificate for each pubkey separate. This means, The pubkey
id_userA_rsa.pub and id_userA_ecdsa.pub start with 1 and each counts up
for itself.
Then i tried to revoke the certificate for id_userA_rsa.pub
(id_userA_rsa-cert.pub) with serial 8. The KRL says, i have to fill one
line with
serial: 8
i can not add a key-id to the serial-number. Only "serial: 8" is possible.
When i check, if certificate is revoked with
ssh-keygen -Qf ... i get a "REVOKED". It's ok.
id_userA_ecdsa-cert.pub has serial 9, so this certificate is not
revoked. But if it has also serial 8, both certificates are revoked.
If i write
id: userA@hostX
in my KRL, all certificates for this pubkey (id) are revoked,
independend from their serial. Its the same effect as if i give the path
to id_userA_rsa-cert.pub or id_userA_rsa.pub.
So if i wand a clean an proper revokation of old certificates, there
MUST be only one incremental-line over all certificates.
This is NOT clear in the man-pages.
Would i be possible, that someone update the docs, that it gets a bit
more understandable for newbies (as me).
thank you
Jakob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--
Douglas E. Engert <DEEngert@xxxxxxxxx>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
