Setting SKID/AKID to "none" in command-line tool gives invalid certificates #28397
Description
I'll upload a PR shortly to fix this. The following command:
openssl req -config "" -x509 -subj "/CN=Test" -nodes -out /tmp/cert.pem -addext "subjectKeyIdentifier = none"
...results in a certificate like this one:
-----BEGIN CERTIFICATE-----
MIICrjCCAZagAwIBAgIUWIp7gRFoWUg69oBTn7hO4hUsqd0wDQYJKoZIhvcNAQEL
BQAwDzENMAsGA1UEAwwEVGVzdDAeFw0yNTA4MzEyMTQzMzZaFw0yNTA5MzAyMTQz
MzZaMA8xDTALBgNVBAMMBFRlc3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC9X9ywVzzJAqzgLL0FMpfqLtYS+1M+7Da4SRe9LFUti8LXBo5XLRNI/+Hj
7hGOhVCvXfTgz417aFY/TKQiVVdY6pwF2Y4Nprs7BMT9oWj4AVvrgkzvgcqmwUZG
fIctgHWuulsIW3rUpNelkhEz9JKQWgedxJ5HmoANpGjE4D4bgGYu2kaLn8hdqhCK
6tWwTaUPSsEKrrqpT/59Z7077SXmXd/v8p/0ou52Dppqzwxkr/B00F60hdAcq3sM
j2w5ShPnMXhZhSh8IBP/V2W0Nq5JSjY+v1FHTRlYNVkFiaIHKOaFQ637LNPgT7HY
FUJnaMZZUFwyVpNOLOX9IHH9ifjNAgMBAAGjAjAAMA0GCSqGSIb3DQEBCwUAA4IB
AQBFaEHhDNO7Bvk1tsAWsiLrT96yTgcCP9RXFJP+Rl6nZB6Fkcl8oe5UmEIEhJFR
H+MmfNH4Lc0+h67pNhC5m8XH1oRoS7UgStUC4HMhDVqzisDodkue7J+VvFm9Wl1H
2B9h9aa6MAvuxMK6KpnZx7ghYyKUMKKEgeS6U7D3OJdz0Wb4xNdIkVALa6z4eNbo
wPzfMGnH6Rzds6YWPv9HDM44n3jExDmWbVzsGkBzh9fZQqsQACe8Vaduodi50JJI
G7wuco9E4SNg/9OclWr76vZG5h2y3kXqvxUo8uSSHurBujQe4xPOIuTSoRg4kMiC
boUqSaIQOoKw8kGidAGEm9tJ
-----END CERTIFICATE-----
This is not a valid certificate. openssl x509 -text does not show this, but if you run it through asn1parse, you'll see:
410:d=2 hl=2 l= 2 cons: cont [ 3 ]
412:d=3 hl=2 l= 0 cons: SEQUENCE
https://github.com/google/der-ascii will also show this. The certificate is encoded with an empty extension list. However, Extensions is declared as:
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
This means an empty list is invalid and not actually an X.509 certificate. If the certificate has no extensions, you are meant to omit the field altogether, not encode an empty sequence. This was caused by #13658 which caused the command-line tool to run through the somewhat unusual pattern of adding an extension and then deleting it later. And then X509_delete_ext does not know to set the extension list back to NULL if it's deleted the last one. The same applies to X509_CRL_delete_ext and X509_REVOKED_delete_ext, but I'm not aware of anyone adding and removing extensions in this way.
The clearest fix is to fix the delete_ext functions.
Aside: That PR is also odd because "none" produces an empty octet string in libcrypto, but only the command-line tool knows to go back and delete it. In other uses of libcrypto, "none" will do the wrong thing. A different design may have been more appropriate.