CA/Certificate generation REQUIRES email address?
-
Attempting to generate a CA or certificate via the cert management tool in the web GUI yields the following error:
"The field Distinguished name Email Address is required."
The emailAddress field is not required in any X.509v3-compliant certificate, unless that certificate is intended for use as an email signing certificate. According to RFC 5280, only a certificate intended to authenticate an email address (such as an email signing certificate) should include an email address at all, and even then, it must be done as an RFC822Name entry under the Subject Alternative Name extension.
Conforming implementations generating new certificates with electronic mail addresses MUST use the rfc822Name in the subject alternative name extension (Section 4.2.1.6) to describe such identities. Simultaneous inclusion of the emailAddress attribute in the subject distinguished name to support legacy implementations is deprecated but permitted.
IMHO, this is a bug; the emailAddress field should be made optional or even omitted entirely. If the need to include an email address in a certificate does truly exist, it should be specified according to RFC 5280.
Version:
2.4.2-RELEASE-p1 (amd64)
built on Tue Dec 12 13:45:26 CST 2017
FreeBSD 11.1-RELEASE-p6 -
I am not seeing a redmine entry on this - maybe I am missing it, my redmine fu is not as good as my google fu..
And while the DN fields do have requirements, I do believe you are correct that email is no longer something that needs to be included. The RFC could be a littler clear if you ask me.. The DN is required but doesn't seem to call out the specifics of what need to be in the DN.
While I love myself some RFC's ;) Sometimes they could be just bit more plain english. These are what is required, these are what are optional..
Should prob put in a redmine for this.
-
The only field that's required in a DN is the CommonName. Quite literally everything else is optional. There are domain-validated certs issued by large public CAs that contain nothing but the CN. Accordingly, that's all that we should be requiring. I'll open a redmine for this.
-
email address I need to sign up, I have access to it.
-
What CA only gives its CN and is in the trust providers out of the box.. Could you please give an example of one of these..
I was under the impression that O and C were required..
-
Let's Encrypt only populates CN and SAN, nothing else.
I believe the current GUI requirements were based on OpenSSL's configuration file default requirements when it was written years ago.
It could most likely be changed as you describe, eventually.
-
Even on their CA?
Looking on their CA now and I see O and C
CN = Let's Encrypt Authority X3
O = Let's Encrypt
C = US -
Right but for self-signed CA/Cert the only bit that really matters is the CN in most cases, though having a weak/small subject makes associating certificates to the CA more difficult in some ways (if importing everything, not creating locally).
It might be nice to leave the optional fields blank, but it's not a priority to change at the moment.
-
I agree there are for sure more important things to address. Should be a minor fix.. Doesn't bother me any or I would put in the redmine about it. So at some point it gets addressed. Curious if he put in a request yet?
Nothing saying that info has to be legit… Just put in root@domain.tld for the email, etc. or noreply@invalid.tld
Not like the CA in pfsense is signing off on any sort of public certs, etc. I do use it all the time for my local stuff. But then again its just me accessing it, etc.
-
There is an entry in Redmine for this at https://redmine.pfsense.org/issues/8381
For internal stuff it doesn't matter much but someone might care more about it when making a CSR to submit to another CA.
-
Thanks for the link to the redmine.. Sure someone will get to sooner or later ;)
