rcgen should refuse emply subject_alt_names

[Stargateur]

Cause webpki refuse it https://github.com/briansmith/webpki/blob/17d9189981a618120fd8217a913828e7418e2484/src/cert.rs#L98-L107

It's lead to:

Rustls: InvalidCertificateData("invalid peer certificate: MissingOrMalformedExtensions")

(not a very explicit error).

I suggest at the very least that generate_simple_self_signed refuse empty vec.

[est31]

not a very explicit error

Yeah this is a general issue with webpki. You should be glad it's not BadDer as that's like half of webpki's errors ;). openssl is defintely better in that regard. If you have problems with a certificate, I recommend you try it out with openssl or one of its forks.

I'm not really sure I want to refuse an empty subject_alt_names list though. I couldn't find the part where the subject alt name extension is mandatory in RFC 5280, although I only skimmed it before writing this comment, so I might miss something. It seems to be mandatory in some instances though, so maybe they mean that? Idk.

[Stargateur]

My main purpose about this issue was for other to find it if they run into this problem too.

I couldn't find the part where the subject alt name extension is mandatory in RFC 5280

I wouldn't be surprise, it's must be a HTTP specific rule or something. I'm fighting with webpki since I start trying to use rustls. I don't understand why rustls have pick webpki, it's too much web oriented, I finally have my simple server running with self signed cert with client authentication, I don't require any verification with webpki cause client only accept the server certificate and same for the server that only accept a list of certificate client and they are exchange securely, only take me weeks to understand how to avoid webpki verification of self signed cert. And now I will live with my dummy subject_alt_names ;) well can't hurt at least they have name now.

maybe:

Where it is non-empty, the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field. A CA
MAY issue more than one certificate with the same DN to the same
subject entity. source

I can't follow a RFC this big