I don't think it makes sense to have a separate flag.
What's the harm in looking at the CN if you don't find a match in the SAN?
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
OpenSSL Project
On Wed, Apr 02, 2014 at 07:24:21AM -0400, Salz, Rich wrote:
I don't think it makes sense to have a separate flag.
What's the harm in looking at the CN if you don't find a match in the SAN?
Well, in fact if any DNS SANs exist, per RFC 6125 and other prior
art, one in fact must not look at the
A quick check of some of our customers shows that out of 4200 SSL certs, 820
have a wildcard CN.
/r$
--
Principal Security Engineer
Akamai Technology
Cambridge, MA
__
OpenSSL Project
On Wed, Apr 02, 2014 at 11:45:05AM -0400, Salz, Rich wrote:
A quick check of some of our customers shows that out of 4200
SSL certs, 820 have a wildcard CN.
Right, I think this makes particular sense for Akamai customers,
for whom you likely host multiple related web sites and coordinating
the
Right, I think this makes particular sense for Akamai customers, for whom you
likely host multiple related web sites and coordinating the deployment of
multiple certs is likely often too complex.
No, these are individual per-site certs for our customers. And just because
you gave me the
On 03/30/2014 03:39 PM, Viktor Dukhovni wrote:
On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote:
- probably useful: while no RFC currently forbids something like *.com you
have a check to disallow wildcards in the two rightmost suffixes. I think
it makes sense to
I, for one, would not want OpenSSL to employ such a complex and fragile
mechanism.
Yeah, it's kinda gross and clunky. On the other hand, it's really all we have
right now, and rejecting a cert with a SAN name of *.com is a good security
thing to do. Perhaps a configure option, or a
Viktor Dukhovni openssl-users at dukhovni.org writes:
On Tue, Apr 01, 2014 at 12:36:18PM -0400, Daniel Kahn Gillmor wrote:
I think the current best approach to this is the public suffix
list, http://publicsuffix.org/ it's a horrible kludge (a
fully-enumerated list of all zones that are
On Tue, Apr 01, 2014 at 05:03:32PM -0400, Salz, Rich wrote:
I, for one, would not want OpenSSL to employ such a complex
and fragile mechanism.
Yeah, it's kinda gross and clunky. On the other hand, it's really
all we have right now, and rejecting a cert with a SAN name of
*.com is a good
Note that the implementation in master (some day 1.1.0) already rejects
*.com, what it fails to reject is *.co.uk
Yes, I understand; my example was wrong, sorry.
I think the onus is on the trusted CA ( that wants to remain trusted) to not
issue such certificates.
And mistake-free?
I am
On Tue, Apr 01, 2014, Viktor Dukhovni wrote:
On Tue, Apr 01, 2014 at 05:03:32PM -0400, Salz, Rich wrote:
I, for one, would not want OpenSSL to employ such a complex
and fragile mechanism.
Yeah, it's kinda gross and clunky. On the other hand, it's really
all we have right now, and
On Wed, Apr 02, 2014 at 12:57:28AM +0200, Dr. Stephen Henson wrote:
I am far from sure the callback is worth the trouble.
The initial aim of X509_check_host was to support minimal host name matching
which until then wasn't in OpenSSL at all. It wasn't intended to cover every
case but to be
On Tue, Apr 01, 2014, Viktor Dukhovni wrote:
What were your plans for X509_VERIFY_PARAM_ID_st for DANE? That's
where the TLSA records were going to be right?
If you post a note about the approach you want to take with extending
X509_VERIFY_PARAM_ID_st I can provide a more complete patch.
Viktor Dukhovni wrote:
I can contribute a patch, that addresses many of the issues. Things
that I'm not immediately planning to address are:
- Separate flag for wildcards in CN vs. wildcards in SAN dnsName.
(LDAP case in RFC 6125).
Just to add context - the LDAP RFCs always
On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote:
Viktor Dukhovni wrote:
I can contribute a patch, that addresses many of the issues. Things
that I'm not immediately planning to address are:
- Separate flag for wildcards in CN vs. wildcards in SAN dnsName.
(LDAP case
Viktor Dukhovni wrote:
On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote:
Viktor Dukhovni wrote:
I can contribute a patch, that addresses many of the issues. Things
that I'm not immediately planning to address are:
- Separate flag for wildcards in CN vs. wildcards in SAN
On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote:
- wrong: according to RFC 6125 section 7.2 only the leftmost label should be
checked for wildcards, but you support also something like
www.*.example.com (there is even a test for it).
Well, wrong is perhaps too
17 matches
Mail list logo
