> On Dec 23, 2018, at 6:01 PM, Kyle Hamilton 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
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
thanks for your reply!
On Tuesday, 18 December 2018, 20:57:40 GMT, Paul Dale
wrote:
There are no committed to dates of any kind at present.
The project is underway but it is too early to set a schedule, yet alone a
completion date.
Pauli
--
Oracle
Dr Paul Dale | Cryptographer |
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 wrote:
>
> SubjectCN is an operational requirement of X.509, I believe. It's not
> optional in the data structure, at any rate.
>
> -Kyle
> On Dec 23, 2018, at 4:29 PM, Kyle Hamilton 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
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 wrote:
>
>
> Salz, Rich via openssl-users wrote:
> > Putting the DNS name in the CN part of the subjectDN has been
In message on Fri, 21 Dec 2018
15:45:23 +0100, Gisle Vanem said:
> I'm trying to understand how the generation of ASM-files
> are done on x64. (I have no problems on x86).
>
> With the generated Nmake makefile from a
> perl Configure VC-WIN64A-ONECORE
>
> when doing a:
> nmake
> On Dec 23, 2018, at 10:21 AM, Michael Richardson 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
Salz, Rich via openssl-users 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.
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
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. wrote:
>
>
> I tried the following
>
> the certificate had a CN oftest.example.com
I tried the following
the certificate had a CN oftest.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)
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. wrote:
>
> On 23.12.2018 03:47, Salz, Rich via openssl-users wrote:
> > > >. New certificates should only use the subjectAltName extension.
> >
> >> Are
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
14 matches
Mail list logo
