Subject CN and SANs

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

Subject CN and SANs

Walter H.
Hello,

I found several different certificates on the net

some are like this:

CN=example.com
SANs are    DNS:example.com, DNS:www.example.com

and some are like this:

CN=www.example.com
SANs are    DNS:example.com, DNS:www.example.com

does this matter or is one them the preferred one?

Thanks,
Walter



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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Felipe Gasper-2
It shouldn’t matter. Technically subject.CN is deprecated anyway, but all the CAs still create it.

-FG


> On Dec 22, 2018, at 4:29 PM, Walter H. <[hidden email]> wrote:
>
> Hello,
>
> I found several different certificates on the net
>
> some are like this:
>
> CN=example.com
> SANs are    DNS:example.com, DNS:www.example.com
>
> and some are like this:
>
> CN=www.example.com
> SANs are    DNS:example.com, DNS:www.example.com
>
> does this matter or is one them the preferred one?
>
> Thanks,
> Walter
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: Subject CN and SANs

OpenSSL - User mailing list
In reply to this post by Walter H.
Putting the DNS name in the CN part of the subjectDN has been deprecated for a very long time (more than 10 years), although it is still supported by many existing browsers. New certificates should only use the subjectAltName extension.
 

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

Re: Subject CN and SANs

Felipe Gasper-2

> On Dec 22, 2018, at 9:12 PM, Salz, Rich via openssl-users <[hidden email]> wrote:
>
> Putting the DNS name in the CN part of the subjectDN has been deprecated for a very long time (more than 10 years), although it is still supported by many existing browsers. New certificates should only use the subjectAltName extension.

Are any CAs actually doing that? I thought they all still included subject.CN.

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

Re: Subject CN and SANs

OpenSSL - User mailing list
   > >. New certificates should only use the subjectAltName extension.
   
>    Are any CAs actually doing that? I thought they all still included subject.CN.
 
Yes, I think commercial CA's still do it.  But that doesn't make my statement wrong :)

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

Re: Subject CN and SANs

Walter H.
On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
>     >  >. New certificates should only use the subjectAltName extension.
>
>>     Are any CAs actually doing that? I thought they all still included subject.CN.
>
> Yes, I think commercial CA's still do it.  But that doesn't make my statement wrong :)
>
Apache raises a warning at the following condition

e.g. a virtual Host defines this:

ServerName  www.example.com:443

and the SSL certificate has a CN which does not correspond to
CN=www.example.com, e.g.  CN=example.com

then the warning looks like this

[Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
www.example.com:443:0 server certificate does NOT include an ID which
matches the server name

and fills up the logs

Walter


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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Kyle Hamilton
Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?

-Kyle H

On Sun, Dec 23, 2018 at 3:25 AM Walter H. <[hidden email]> wrote:

>
> On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
> >     >  >. New certificates should only use the subjectAltName extension.
> >
> >>     Are any CAs actually doing that? I thought they all still included subject.CN.
> >
> > Yes, I think commercial CA's still do it.  But that doesn't make my statement wrong :)
> >
> Apache raises a warning at the following condition
>
> e.g. a virtual Host defines this:
>
> ServerName  www.example.com:443
>
> and the SSL certificate has a CN which does not correspond to
> CN=www.example.com, e.g.  CN=example.com
>
> then the warning looks like this
>
> [Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
> www.example.com:443:0 server certificate does NOT include an ID which
> matches the server name
>
> and fills up the logs
>
> Walter
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Walter H.

I tried the following

the certificate had a CN of    test.example.com   and in subjectAltNames
dNS were
test.example.com  and test.example.net

when the Apache ServerName is   test.example.net  I get this warning

[Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN)
`test.example.com' does NOT match server name!?

so the CN matters ...

so the server behavior is something different to the behavior of the
client ...

Walter

On 23.12.2018 10:44, Kyle Hamilton wrote:

> Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?
>
> -Kyle H
>
> On Sun, Dec 23, 2018 at 3:25 AM Walter H.<[hidden email]>  wrote:
>> On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
>>>      >   >. New certificates should only use the subjectAltName extension.
>>>
>>>>      Are any CAs actually doing that? I thought they all still included subject.CN.
>>> Yes, I think commercial CA's still do it.  But that doesn't make my statement wrong :)
>>>
>> Apache raises a warning at the following condition
>>
>> e.g. a virtual Host defines this:
>>
>> ServerName  www.example.com:443
>>
>> and the SSL certificate has a CN which does not correspond to
>> CN=www.example.com, e.g.  CN=example.com
>>
>> then the warning looks like this
>>
>> [Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
>> www.example.com:443:0 server certificate does NOT include an ID which
>> matches the server name
>>
>> and fills up the logs
>>
>> Walter

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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Felipe Gasper-2
Wow that’s pretty bad .. is that the current version of httpd??

That’d be worth a big report if so, IMO, though I’d imagine it’s an issue they’re aware of.

-FG

> On Dec 23, 2018, at 6:53 AM, Walter H. <[hidden email]> wrote:
>
>
> I tried the following
>
> the certificate had a CN of    test.example.com   and in subjectAltNames dNS were
> test.example.com  and test.example.net
>
> when the Apache ServerName is   test.example.net  I get this warning
>
> [Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN) `test.example.com' does NOT match server name!?
>
> so the CN matters ...
>
> so the server behavior is something different to the behavior of the client ...
>
> Walter
>
>> On 23.12.2018 10:44, Kyle Hamilton wrote:
>> Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?
>>
>> -Kyle H
>>
>>> On Sun, Dec 23, 2018 at 3:25 AM Walter H.<[hidden email]>  wrote:
>>>> On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
>>>>     >   >. New certificates should only use the subjectAltName extension.
>>>>
>>>>>     Are any CAs actually doing that? I thought they all still included subject.CN.
>>>> Yes, I think commercial CA's still do it.  But that doesn't make my statement wrong :)
>>>>
>>> Apache raises a warning at the following condition
>>>
>>> e.g. a virtual Host defines this:
>>>
>>> ServerName  www.example.com:443
>>>
>>> and the SSL certificate has a CN which does not correspond to
>>> CN=www.example.com, e.g.  CN=example.com
>>>
>>> then the warning looks like this
>>>
>>> [Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
>>> www.example.com:443:0 server certificate does NOT include an ID which
>>> matches the server name
>>>
>>> and fills up the logs
>>>
>>> Walter
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: Subject CN and SANs

Walter H.
I guess its a matter of which Linux you use,

CentOS 7 doesn't give this warning;
CentOS 6 warns about this;

a Debian (don't really know which release)
uname -a
Linux a2f78 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64
GNU/Linux
does warn ...

Walter

On 23.12.2018 13:21, Felipe Gasper wrote:

> Wow that’s pretty bad .. is that the current version of httpd??
>
> That’d be worth a big report if so, IMO, though I’d imagine it’s an issue they’re aware of.
>
> -FG
>
>> On Dec 23, 2018, at 6:53 AM, Walter H.<[hidden email]>  wrote:
>>
>>
>> I tried the following
>>
>> the certificate had a CN of    test.example.com   and in subjectAltNames dNS were
>> test.example.com  and test.example.net
>>
>> when the Apache ServerName is   test.example.net  I get this warning
>>
>> [Sun Dec 23 12:45:03 2018] [warn] RSA server certificate CommonName (CN) `test.example.com' does NOT match server name!?
>>
>> so the CN matters ...
>>
>> so the server behavior is something different to the behavior of the client ...
>>
>> Walter
>>
>>> On 23.12.2018 10:44, Kyle Hamilton wrote:
>>> Does Apache only examine CN=, or does it also check subjectAltNames dNS entries?
>>>
>>> -Kyle H
>>>
>>>> On Sun, Dec 23, 2018 at 3:25 AM Walter H.<[hidden email]>   wrote:
>>>>> On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
>>>>>      >    >. New certificates should only use the subjectAltName extension.
>>>>>
>>>>>>      Are any CAs actually doing that? I thought they all still included subject.CN.
>>>>> Yes, I think commercial CA's still do it.  But that doesn't make my statement wrong :)
>>>>>
>>>> Apache raises a warning at the following condition
>>>>
>>>> e.g. a virtual Host defines this:
>>>>
>>>> ServerName  www.example.com:443
>>>>
>>>> and the SSL certificate has a CN which does not correspond to
>>>> CN=www.example.com, e.g.  CN=example.com
>>>>
>>>> then the warning looks like this
>>>>
>>>> [Fri Dec 07 07:08:19.393876 2018] [ssl:warn] [pid 29746] AH01909:
>>>> www.example.com:443:0 server certificate does NOT include an ID which
>>>> matches the server name
>>>>
>>>> and fills up the logs
>>>>
>>>> Walter
>>


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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Michael Richardson
In reply to this post by OpenSSL - User mailing list

Salz, Rich via openssl-users <[hidden email]> wrote:
    > Putting the DNS name in the CN part of the subjectDN has been
    > deprecated for a very long time (more than 10 years), although it
    > is still supported by many existing browsers. New certificates
    > should only use the subjectAltName extension.

Fair enough.

It seems that the "openssl ca" mechanism still seem to want a subjectDN
defined.  Am I missing some mechanism that would let me omit all of that?  Or
is a patch needed to kill what seems like a current operational requirement?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Viktor Dukhovni
> On Dec 23, 2018, at 10:21 AM, Michael Richardson <[hidden email]> wrote:
>
> It seems that the "openssl ca" mechanism still seem to want a subjectDN
> defined.  Am I missing some mechanism that would let me omit all of that?  Or
> is a patch needed to kill what seems like a current operational requirement?

It is not a matter of "openssl ca".  An X.509 certificate has a subjectDN,
that's a required part of the certificate structure.  However, a "DN" is a
SEQUENCE of "RDNs", and that sequence can be empty, for example (requires "bash"):

  $ openssl req -config <(
          printf "%s\n[dn]\n%s\n[ext]\n%s\n" \
            "distinguished_name = dn" \
            "prompt = yes" \
            "$(printf "subjectAltName = DNS:%s\n" "example.com")"
          ) \
        -extensions ext -new -newkey rsa:1024 -nodes -keyout /dev/null \
        -x509 -subj / 2>/dev/null |
      openssl x509 -noout -text -certopt no_pubkey,no_sigdump
  Certificate:
      Data:
          Version: 3 (0x2)
          Serial Number:
              47:37:cb:39:a4:9c:be:c2:ea:42:2f:ed:e2:df:bc:62:bb:2b:cb:dd
          Signature Algorithm: sha256WithRSAEncryption
          Issuer:
          Validity
              Not Before: Dec 23 18:56:08 2018 GMT
              Not After : Jan 22 18:56:08 2019 GMT
          Subject:
          X509v3 extensions:
              X509v3 Subject Alternative Name:
                  DNS:example.com

Note the empty subjectDN and issuerDN.  The latter violates RFC5280, but
will suffice for this example.  An RFC compliant *self-signed* certificate
needs to have a non-empty issuer name, so it could be something like:

  $ openssl req -config <(
          printf "%s\n[dn]\n%s\n[ext]\n%s\n" \
            "distinguished_name = dn" \
            "prompt = yes" \
            "$(printf "subjectAltName = DNS:%s\n" "example.com")"
          ) \
        -extensions ext -new -newkey rsa:1024 -nodes -keyout /dev/null \
        -x509 -subj "/O=Self" 2>/dev/null |
      openssl x509 -noout -text -certopt no_pubkey,no_sigdump
  Certificate:
      Data:
          Version: 3 (0x2)
          Serial Number:
              6b:f0:9e:6c:ff:27:f3:cb:eb:79:10:6d:ac:9a:c2:54:e4:78:06:b0
          Signature Algorithm: sha256WithRSAEncryption
          Issuer: O = Self
          Validity
              Not Before: Dec 23 19:08:51 2018 GMT
              Not After : Jan 22 19:08:51 2019 GMT
          Subject: O = Self
          X509v3 extensions:
              X509v3 Subject Alternative Name:
                  DNS:example.com

with an actual CA, the subject could be empty, and the issuer will be the
CA's DN.

--
        Viktor.

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

Re: Subject CN and SANs

Kyle Hamilton
In reply to this post by Michael Richardson
SubjectCN is an operational requirement of X.509, I believe.  It's not
optional in the data structure, at any rate.

-Kyle H

On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson <[hidden email]> wrote:

>
>
> Salz, Rich via openssl-users <[hidden email]> wrote:
>     > Putting the DNS name in the CN part of the subjectDN has been
>     > deprecated for a very long time (more than 10 years), although it
>     > is still supported by many existing browsers. New certificates
>     > should only use the subjectAltName extension.
>
> Fair enough.
>
> It seems that the "openssl ca" mechanism still seem to want a subjectDN
> defined.  Am I missing some mechanism that would let me omit all of that?  Or
> is a patch needed to kill what seems like a current operational requirement?
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Viktor Dukhovni


> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton <[hidden email]> wrote:
>
> SubjectCN is an operational requirement of X.509, I believe.

You're confusing the DN and the CN.

>  It's not optional in the data structure, at any rate.

The subjectDN is not optional, but it can be empty sequence, and
is empty for domains whose name exceeds the CN length limit of either
63 or 64 characters (can't recall which of the two just now, but that
is not important).

--
        Viktor.

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

Re: Subject CN and SANs

Felipe Gasper-2
In reply to this post by Kyle Hamilton
Actually, per the latest CA/Browser forum guidelines, subject.CN is not only optional but “discouraged”.

-FG

> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton <[hidden email]> wrote:
>
> SubjectCN is an operational requirement of X.509, I believe.  It's not
> optional in the data structure, at any rate.
>
> -Kyle H
>
>> On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson <[hidden email]> wrote:
>>
>>
>> Salz, Rich via openssl-users <[hidden email]> wrote:
>>> Putting the DNS name in the CN part of the subjectDN has been
>>> deprecated for a very long time (more than 10 years), although it
>>> is still supported by many existing browsers. New certificates
>>> should only use the subjectAltName extension.
>>
>> Fair enough.
>>
>> It seems that the "openssl ca" mechanism still seem to want a subjectDN
>> defined.  Am I missing some mechanism that would let me omit all of that?  Or
>> is a patch needed to kill what seems like a current operational requirement?
>>
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh networks [
>> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
>> ]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

Re: Subject CN and SANs

Kyle Hamilton
In reply to this post by Viktor Dukhovni
You're right, I typoed.  SubjectDN is non-optional.  But it can, as
you mentioned, be an empty sequence.

But for PKIX purposes, it can't be empty if it's an Issuer (because
IssuerDN can't be empty in the certificates that it issues).

-Kyle H

On Sun, Dec 23, 2018 at 3:35 PM Viktor Dukhovni
<[hidden email]> wrote:

>
>
>
> > On Dec 23, 2018, at 4:29 PM, Kyle Hamilton <[hidden email]> wrote:
> >
> > SubjectCN is an operational requirement of X.509, I believe.
>
> You're confusing the DN and the CN.
>
> >  It's not optional in the data structure, at any rate.
>
> The subjectDN is not optional, but it can be empty sequence, and
> is empty for domains whose name exceeds the CN length limit of either
> 63 or 64 characters (can't recall which of the two just now, but that
> is not important).
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Viktor Dukhovni


> On Dec 23, 2018, at 6:01 PM, Kyle Hamilton <[hidden email]> wrote:
>
> You're right, I typoed.  SubjectDN is non-optional.  But it can, as
> you mentioned, be an empty sequence.
>
> But for PKIX purposes, it can't be empty if it's an Issuer (because
> IssuerDN can't be empty in the certificates that it issues).

That's an odd use of "it", since the issuerDN while also a DN is not
a subjectDN.  The "it" that is the subjectDN is sometimes legitimately
empty.  The other "it" that is the issuerDN is supposed to always be
non-empty, but some self-signed certificates violate that requirement
with apparent impunity, e.g. nothing in OpenSSL requires a non-empty
issuer DN in an end-entity self-signed certificate, if it breaks, the
constraint would be at the application layer.

--
        Viktor.

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

Re: Subject CN and SANs

Walter H.
In reply to this post by Felipe Gasper-2
and which CA does this as the forum guidelines say?

On 23.12.2018 22:50, Felipe Gasper wrote:
> Actually, per the latest CA/Browser forum guidelines, subject.CN is not only optional but “discouraged”.
>
> -FG
>



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

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Subject CN and SANs

Chris Gray-4
In reply to this post by Felipe Gasper-2
A bit off-topic but is it also a good idea to follow these guidelines in
non-browser use cases, for example for a client certificate which is used
to autenticate on a TLS connection which will be used for another protocol
such as MQTT? In this case the SubjectCN looks like a "natural" place to
put the client's identity, but maybe it is still better to use
subjectAltName?

 - Chris

> Actually, per the latest CA/Browser forum guidelines, subject.CN is not
> only optional but “discouraged”.
>
> -FG
>
>> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton <[hidden email]> wrote:
>>
>> SubjectCN is an operational requirement of X.509, I believe.  It's not
>> optional in the data structure, at any rate.
>>
>> -Kyle H
>>
>>> On Sun, Dec 23, 2018 at 9:22 AM Michael Richardson <[hidden email]>
>>> wrote:
>>>
>>>
>>> Salz, Rich via openssl-users <[hidden email]> wrote:
>>>> Putting the DNS name in the CN part of the subjectDN has been
>>>> deprecated for a very long time (more than 10 years), although it
>>>> is still supported by many existing browsers. New certificates
>>>> should only use the subjectAltName extension.
>>>
>>> Fair enough.
>>>
>>> It seems that the "openssl ca" mechanism still seem to want a subjectDN
>>> defined.  Am I missing some mechanism that would let me omit all of
>>> that?  Or
>>> is a patch needed to kill what seems like a current operational
>>> requirement?
>>>
>>> --
>>> ]               Never tell me the odds!                 | ipv6 mesh
>>> networks [
>>> ]   Michael Richardson, Sandelman Software Works        |    IoT
>>> architect   [
>>> ]     [hidden email]  http://www.sandelman.ca/        |   ruby on
>>> rails    [
>>>
>>> --
>>> openssl-users mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


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

Re: Subject CN and SANs

Felipe Gasper-2
In reply to this post by Walter H.
I’m not sure, heh. ;-)

-F

> On Dec 24, 2018, at 3:17 AM, Walter H. <[hidden email]> wrote:
>
> and which CA does this as the forum guidelines say?
>
>> On 23.12.2018 22:50, Felipe Gasper wrote:
>> Actually, per the latest CA/Browser forum guidelines, subject.CN is not only optional but “discouraged”.
>>
>> -FG
>>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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