On 08/17/2017 12:56 AM, Jeffrey Walton wrote:
On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote:
I have skimmed through a few RFCs following today's postings and a few web
sites. It would seem to me that I should:
Remove commonName and emailAddress completely from the cnf file. They no
longer belong in any cert, root or intermediate CA certs, server or user
certs.
CommonName is supplied for viewing by tools like certificate viewers.
It should probably be a friendly name, like "Example Web Services".
Don't include hostnames in the CN. If you list it in the CN, then it
must be listed in the SAN, too. You must list it twice.
When you see a name like "example.com" in the CN, its usually a CA
including a domain name and not a hostname. It confusing for users and
user agents. I've seen user agents match a hostname based on the
domain name.
On the backend, there's usually a redirect for the domain example.com
to send user agents to a host like www.example.com. It happens up at
layer 7, not at layer 4.
So commonName does make some sense, for those that want to verbosely
define the name. But not for fqdns.
For servers include something like in the cnf file:
subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
EMAIL:postmaster@xxxxxxxxxxx
Don't include an email address.
X.509 and PKIX certificates don't really have a proper field for email
addresses. That's why they get mashed into CommonName.
I have looked through a lot of rfcs and do not see this. If you mean a
full email address like
Jeffrey Walton <noloader@xxxxxxxxx>
I see that. And it explains the mashing you see when you display the
subjectName:
CN=www.htt-consult.com/emailAddress=admin@xxxxxxxxxxxxxxx
Yes, I now know I should not have put the fqdn in there....
But
subjectAltName = email:hostmaster@xxxxxxxxxxx
Clearly is a valid rfc822name and is a proper email address for server
contact and even user certs.
So why do you recommend NOT putting email address in SAN when so many
others DO recommend it. Is there some clear directive from some forum
(CA/B BR)? And it seems this is how Microsoft encodes email addresses
(but not user names, see below).
(That is all suppose to be on a single line in case your mail viewer wraps
it).
Um, I can specify 'localhost' in this manner if I am on the server and
connecting in the browser with https://localhost ??
Yes.
You can also put IP addresses there. The RFC's mostly allow it. The
CA/Browser Forum Baseline Requirements (CA/B BR) forbids it, but its
not clear (to me) what current browser behavior is.
For completeness, non-browser user agents, like wget and openssl,
follow the RFC standards and issuing policies. Browsers follow the
CA/B BR. That's why you often see browsers reject something accepted
by other user agents.
You might also be interested in
https://stackoverflow.com/questions/21297139/how-do-you-sign-certificate-signing-request-with-your-certification-authority/21340898#21340898
and https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl.
They questions and answers reference about 6 different standards.
And for clients:
subjectAltName = EMAIL:user@xxxxxxxxxxx
I am looking at how to build the above line using ENV variables. It is more
a matter of how I do it than can I do it...
This is a whole 'nother can of worms. Also see
https://security.stackexchange.com/questions/62746/how-to-encode-a-username-in-pkix-certificate.
Fun read. Since I am not striving for MS coordination, and so far I
have not dove into LDAP issues, I would go for DN/UID added to the user
cnf file.
thanks
Bob
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
