Implementing deprecation of commonname and emailaddress

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Implementing deprecation of commonname and emailaddress

Robert Moskowitz
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.

For servers include something like in the cnf file:

subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
EMAIL:[hidden email]

(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 ??

And for clients:

subjectAltName = EMAIL:[hidden email]

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...

thanks for any advice

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

Jeffrey Walton-3
On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz <[hidden email]> 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.

> For servers include something like in the cnf file:
>
> subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
> EMAIL:[hidden email]

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.

> (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:[hidden email]
>
> 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.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

Robert Moskowitz


On 08/17/2017 12:56 AM, Jeffrey Walton wrote:

> On Thu, Aug 17, 2017 at 12:28 AM, Robert Moskowitz <[hidden email]> 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:[hidden email]
> 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 <[hidden email]>

I see that.  And it explains the mashing you see when you display the
subjectName:

CN=www.htt-consult.com/emailAddress=[hidden email]

Yes, I now know I should not have put the fqdn in there....

But

subjectAltName      = email:[hidden email]

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:[hidden email]
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

Viktor Dukhovni
In reply to this post by Jeffrey Walton-3
On Thu, Aug 17, 2017 at 12:56:20AM -0400, Jeffrey Walton wrote:

> > 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".

RFC 5280 suggests an empty subject DN with all the desired names
in the the subject alt name extension.

> When you see a name like "example.com" in the CN, its usually a CA
> including a domain name and not a hostname.

That's nonsense.

> > For servers include something like in the cnf file:
> >
> > subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
> > EMAIL:[hidden email]
>
> Don't include an email address.

That is, don't incude unless the certificate is intended for S/MIME.

> X.509 and PKIX certificates don't really have a proper field for email
> addresses. That's why they get mashed into CommonName.

They sure do, that what's rfc822Name is for in the subject alt name
extenstion.  It supports S/MIME certificates.  There's even recent
work (soon to be an RFC) to internationalize this with SmtpUTF8Name...

> > 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, but it is not a good idea.  Since that "localhost" will
then work on every host that trusts the issuing CA.  The only way
to make this reasonably secure is to have a per-host issuing CA
that's only trusted on *that* host, and *that* CA can then issue
the "localhost" certificate.  All the hosts can additionally
trust other shared CAs.

> > 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...

The tricky bit is creating a variable number of SAN elements, I don't
know how to do that with just environment variables.  Sometimes building
a config file on the fly is the way to go.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

Jeffrey Walton-3
>> When you see a name like "example.com" in the CN, its usually a CA
>> including a domain name and not a hostname.
>
> That's nonsense.

If a certificate is issued under CA/B policies, and CN=example.com but
it _lacks_ SAN=example.com, then its a not a hostname and it should
not be matched.

I'm aware of OpenSSL's behavior in the matter. But OpenSSL does not
understand issuing policies so its easy to confuse.

Forgive me if OpenSSL is now imbued with knowledge of issuing policies
and how matching should occur outside of the RFCs.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

Robert Moskowitz
In reply to this post by Viktor Dukhovni
Viktor,

thanks for the reply.

On 08/17/2017 11:15 AM, Viktor Dukhovni wrote:

> On Thu, Aug 17, 2017 at 12:56:20AM -0400, Jeffrey Walton wrote:
>
>>> 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".
> RFC 5280 suggests an empty subject DN with all the desired names
> in the the subject alt name extension.
>
>> When you see a name like "example.com" in the CN, its usually a CA
>> including a domain name and not a hostname.
> That's nonsense.
>
>>> For servers include something like in the cnf file:
>>>
>>> subjectAltName = DNS:www.example.com, DNS:example.com, DNS=localhost,
>>> EMAIL:[hidden email]
>> Don't include an email address.
> That is, don't incude unless the certificate is intended for S/MIME.

Or to provide an easy way to contact the server admin if there is a
problem/question with the cert?  Even without S/MIME?

>
>> X.509 and PKIX certificates don't really have a proper field for email
>> addresses. That's why they get mashed into CommonName.
> They sure do, that what's rfc822Name is for in the subject alt name
> extenstion.  It supports S/MIME certificates.  There's even recent
> work (soon to be an RFC) to internationalize this with SmtpUTF8Name...

That is what I thought, too.  Just not the full email format like:

Viktor Dukhovni <[hidden email]>

>
>>> 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, but it is not a good idea.  Since that "localhost" will
> then work on every host that trusts the issuing CA.  The only way
> to make this reasonably secure is to have a per-host issuing CA
> that's only trusted on *that* host, and *that* CA can then issue
> the "localhost" certificate.  All the hosts can additionally
> trust other shared CAs.

So better to provide a self-signed cert if a server is going to be
accessed from a browser on the server via https://localhost

>
>>> 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...
> The tricky bit is creating a variable number of SAN elements, I don't
> know how to do that with just environment variables.  Sometimes building
> a config file on the fly is the way to go.
>
The simplest that I have come up with is:

export SAN = "DNS:example.com, DNS:www.example.com,
EMAIL:[hidden email]"

and in the cnf

subjectAltName = $SAN

I think.   I am not yet up to testing this....

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

OpenSSL - User mailing list
In reply to this post by Jeffrey Walton-3

> Le 17 août 2017 à 17:26, Jeffrey Walton <[hidden email]> a écrit :
>
>>> When you see a name like "example.com" in the CN, its usually a CA
>>> including a domain name and not a hostname.
>>
>> That's nonsense.
>
> If a certificate is issued under CA/B policies, and CN=example.com but
> it _lacks_ SAN=example.com, then its a not a hostname and it should
> not be matched.

Such a certificate would be mis-issued and be revoked immediately. CN MUST be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in CN MUST be present in the SAN extension.

Cordialement,
Erwann Abalea

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

Jeffrey Walton-3
On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
<[hidden email]> wrote:

>
>> Le 17 août 2017 à 17:26, Jeffrey Walton <[hidden email]> a écrit :
>>
>>>> When you see a name like "example.com" in the CN, its usually a CA
>>>> including a domain name and not a hostname.
>>>
>>> That's nonsense.
>>
>> If a certificate is issued under CA/B policies, and CN=example.com but
>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>> not be matched.
>
> Such a certificate would be mis-issued and be revoked immediately. CN MUST be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in CN MUST be present in the SAN extension.

Oh, you would have some fun watching how various user agents handle
that scenario. For your first stop, check out how OpenSSL handles it.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Implementing deprecation of commonname and emailaddress

OpenSSL - User mailing list

> Le 17 août 2017 à 17:36, Jeffrey Walton <[hidden email]> a écrit :
>
> On Thu, Aug 17, 2017 at 11:34 AM, Erwann Abalea
> <[hidden email]> wrote:
>>
>>> Le 17 août 2017 à 17:26, Jeffrey Walton <[hidden email]> a écrit :
>>>
>>>>> When you see a name like "example.com" in the CN, its usually a CA
>>>>> including a domain name and not a hostname.
>>>>
>>>> That's nonsense.
>>>
>>> If a certificate is issued under CA/B policies, and CN=example.com but
>>> it _lacks_ SAN=example.com, then its a not a hostname and it should
>>> not be matched.
>>
>> Such a certificate would be mis-issued and be revoked immediately. CN MUST be an FQDN (or a wild carded FQDN, or an IP address), and a copy of the value in CN MUST be present in the SAN extension.
>
> Oh, you would have some fun watching how various user agents handle
> that scenario. For your first stop, check out how OpenSSL handles it.

I’m sure some user agents can have strange behaviors on such certificates. My remark took into consideration the CA/B policies. If such a certificate falls down under the CA/B policies (issued by a public CA, and a TLS server certificate), then it’s invalid.
Some browsers (maybe all?) ignore the CN if the SAN extension is present, even for private CAs.

Cordialement,
Erwann Abalea

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users