Intent to Remove: Support for commonName matching in certificates

22,339 views
Skip to first unread message

Ryan Sleevi

unread,
Jan 27, 2017, 7:45:39 PM1/27/17
to blink-dev
Primary eng (and PM) emails
rsl...@chromium.org awha...@chromium.org

Link to "Intent to Deprecate" thread
No deprecate thread; it's been deprecated since HTTPS was first introduced (RFC 2818) in 2000.

Summary
Certificates have two ways to express the domain/IP they're bound to - one which is unstructured and ambiguous (commonName), and one which is well-defined (subjectAltName). In the absence of any subjectAltNames, Chrome currently falls back to comparing the domain against the commonName, if present.

This proposal is to remove that fallback path; in effect, requiring a subjectAltName. Ideally, we would do this for all certificates (publicly trusted and privately trusted), but if there are concerns about compat risk, we can restrict it to publicly trusted certificates.

Motivation
Since 1997 (X.509v3's ratification), certificates have had two ways to express a binding to a domain name - either via the commonName attribute within the certificate's subject, or via the explicitly typed (dNSName or iPAddress) of the SubjectAlternativeName Extension.

Since RFC 2818 (published in 2000, first drafted in January 1998), the use of the commonName field has been considered deprecated, because it's ambiguous and untyped - that is, it might contain a human-readable name or it might be a domain name.

The use of the subjectAlternativeName fields leaves it unambiguous whether a certificate is expressing a binding to an IP address or a domain name, and is fully defined in terms of its interaction with Name Constraints. commonName, however, is ambiguous, and because of this, support for the commonName has been a source of security bugs - in both Chrome and the libraries it uses and within the TLS ecosystem at large.

Compatibility Risk
Low. RFC 2818 has deprecated this for nearly two decades, and the Baseline Requirements (which all publicly trusted CAs must abide by) has required the presence of a subjectAltName since 2012.

Mozilla Firefox already requires the subjectAltName for any newly issued publicly trusted certificates since Firefox 48 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 ).

Usage information
From a metrics perspective, less than .002% of publicly trusted certificate validations would require this behaviour (Net.CertCommonNameFallback minus Net.CertCommonNameFallbackPrivateCA).

As 1.57% of privately-trusted CA certificates rely on this behaviour (or 0.1% of all certificate validations), it may be premature to deprecate it for privately-trusted CAs; alternatively, we could remove it with an enterprise policy to allow it for a limited number of releases. Unfortunately, despite being deprecated for nearly 20 years, it's unlikely we'd be able to drive this number down (and improve the security of the ecosystem) without taking further action.

OWP launch tracking bug

Entry on the feature dashboard
https://www.chromestatus.com/feature/4981025180483584 (Apologies if I botched this; not sure how to capture "The standard says this is deprecated, and Mozilla supports deprecating")

fatm...@gmail.com

unread,
Feb 1, 2017, 4:25:25 AM2/1/17
to Security-dev, blin...@chromium.org, rsl...@chromium.org
RFC 2818 states: (Section 3.1, para 4)

"If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead."

By removing support for the CN field, surely Chrome becomes RFC non-compliant (regardless of deprecation) because the RFC states that "Common Name field in the Subject field of the certificate MUST be used" if the CN is not present? How can the MUST be obeyed if the certificate contains only a populated CN field and no populated subjectAltName field if the use of CN is deprecated in Chrome?

In any case, from the perspective of private PKIs, this may be challenging from an operational perspective. For example, the default "WebServer" template in Microsoft ADCS does not use subjectAltName. Whilst this default template can be copied and modified to include the subjectAltName field, reissuance of all these already issued Web Server certificates may be a significant undertaking for those organisations with private PKIs using Chrome if this policy is implemented.

Ryan Sleevi

unread,
Feb 1, 2017, 2:00:10 PM2/1/17
to fatm...@gmail.com, Security-dev, blink-dev, Ryan Sleevi
On Wed, Feb 1, 2017 at 1:25 AM, <fatm...@gmail.com> wrote:
RFC 2818 states: (Section 3.1, para 4)

"If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead."

By removing support for the CN field, surely Chrome becomes RFC non-compliant (regardless of deprecation) because the RFC states that "Common Name field in the Subject field of the certificate MUST be used" if the CN is not present? How can the MUST be obeyed if the certificate contains only a populated CN field and no populated subjectAltName field if the use of CN is deprecated in Chrome?

RFC 6125
 
In any case, from the perspective of private PKIs, this may be challenging from an operational perspective. For example, the default "WebServer" template in Microsoft ADCS does not use subjectAltName. Whilst this default template can  be copied and modified to include the subjectAltName field, reissuance of all these already issued Web Server certificates may be a significant undertaking for those organisations with private PKIs using Chrome if this policy is implemented.

It might be; however, Microsoft ADCS is also AD integrated for deployment of those certificates, so it's also arguable that resolving that issue may not be a significant undertaking, because ADCS is highly automated.

In such situations, we rely on our data, enterprise policy controls, and enterprise policy support team, all of which indicate that this concern is unlikely to actually manifest as a significant customer issue. 

bhu...@gmail.com

unread,
Feb 3, 2017, 12:37:42 AM2/3/17
to Security-dev, blin...@chromium.org, rsl...@chromium.org
We use our MS CA for other non AD integrated applications, and we actually have the subjectAltName field disabled for any certificates that are only authenticating one domain, user, device, etc. and only have the Common Name field to verify against.

There may be others in this situation as Microsoft actually recommends disabling the SubectAltName field, see this link https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

Nathan

PhistucK

unread,
Feb 3, 2017, 2:04:08 AM2/3/17
to bhu...@gmail.com, Security-dev, blink-dev, Ryan Sleevi
:S
So who is right? Microsoft sort of says that only using commonName prevents impersonation attacks and this intent says it is sort of the other way around. :(


PhistucK


--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Adam Langley

unread,
Feb 3, 2017, 11:05:55 AM2/3/17
to bhu...@gmail.com, Security-dev, blink-dev, Ryan Sleevi
On Thu, Feb 2, 2017 at 9:37 PM, <bhu...@gmail.com> wrote:
We use our MS CA for other non AD integrated applications, and we actually have the subjectAltName field disabled for any certificates that are only authenticating one domain, user, device, etc. and only have the Common Name field to verify against.

There may be others in this situation as Microsoft actually recommends disabling the SubectAltName field, see this link https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

The document merely notes that SANs need to be carefully reviewed because they specify who a certificate is being issued for. However, if you only use commonNames then you already have to review those names to the same standard. Like many other extension fields, the SAN is sensitive and MS are right to highlight that, but there's no argument there for continuing to wedge hostnames into CN.


Cheers

AGL

bhu...@gmail.com

unread,
Feb 7, 2017, 9:58:16 PM2/7/17
to Security-dev
Any Idea what the time frame would be to make the change for private CA's or when you may know if they will be included/excluded for this update to chrome?
I have verified our publicly signed certificates would not be affected.

However, we would need to modify the registry value indicated in the previous article to enable rather then disable the use of the subjectAltName field on our MS CAs and reissue all affected certificates. Hopefully prior to the implementation of this Chrome change...

Ryan Sleevi

unread,
Feb 8, 2017, 9:11:25 PM2/8/17
to bhu...@gmail.com, Security-dev
I'm exploring this with our Enterprise teams to assess the best path to support enterprises such as yourself that may need additional time to accommodate such changes, while also ensuring the vast majority of Chrome users are safe, and setting an appropriate expectation for the timeframe to remove the code. 

ravi...@gmail.com

unread,
Apr 19, 2017, 8:53:40 PM4/19/17
to Security-dev, bhu...@gmail.com, rsl...@chromium.org
It looks like this change was pushed with Chrome 58 and certificates issued by private CAs are impacted. The initial post and the comments indicated - it would be premature to push this change for certs issued by private PKIs.

Ryan Sleevi

unread,
Apr 19, 2017, 9:03:13 PM4/19/17
to ravi...@gmail.com, Security-dev, Nathan Allen, Ryan Sleevi


On Wed, Apr 19, 2017 at 8:53 PM, <ravi...@gmail.com> wrote:
It looks like this change was pushed with Chrome 58 and certificates issued by private CAs are impacted. The initial post and the comments indicated - it would be premature to push this change for certs issued by private PKIs.

"As 1.57% of privately-trusted CA certificates rely on this behaviour (or 0.1% of all certificate validations), it may be premature to deprecate it for privately-trusted CAs; alternatively, we could remove it with an enterprise policy to allow it for a limited number of releases. Unfortunately, despite being deprecated for nearly 20 years, it's unlikely we'd be able to drive this number down (and improve the security of the ecosystem) without taking further action."

An enterprise policy was added for a limited number of releases. EnableCommonNameFallbackForLocalAnchors

Ravi Yalamanchili

unread,
Apr 19, 2017, 9:09:09 PM4/19/17
to rsl...@chromium.org, Security-dev, Nathan Allen
This thread had no activity from early Feb and we were not aware of this change until our browsers were upgraded today. Is there one location where we can follow upcoming changes to Chrome?

PhistucK

unread,
Apr 20, 2017, 2:05:53 AM4/20/17
to Ravi Yalamanchili, Dru Knox, Ryan Sleevi, Security-dev, Nathan Allen
The Chromium blog should announce this kind of information, however, it seems to be missing this change. :(

Just using the beta channel will likely be useful in this regard.


PhistucK

Ryan Sleevi

unread,
Apr 20, 2017, 10:07:55 AM4/20/17
to PhistucK, Ravi Yalamanchili, Dru Knox, Ryan Sleevi, Security-dev, Nathan Allen
Yeah, I'm not sure how this didn't end up there. I'll try to figure out where the draft changes went, as awhalley@ and I both tried to make sure it went out as part of the communications for 58's promotions along the way.

pavel....@gmail.com

unread,
Apr 24, 2017, 1:11:10 AM4/24/17
to Security-dev, ravi...@gmail.com, dk...@chromium.org, rsl...@chromium.org, bhu...@gmail.com
Yes, I agree, absolutely there should be some anouncement ... like changing padding lock icon with information this kind of connection will be deprecated. Upgrading to Chrome 58 just killed our company internal connections without any warning.

Dne čtvrtek 20. dubna 2017 8:05:53 UTC+2 PhistucK napsal(a):
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

mathew

unread,
Apr 24, 2017, 10:34:03 AM4/24/17
to Security-dev, ravi...@gmail.com, dk...@chromium.org, rsl...@chromium.org, bhu...@gmail.com, pavel....@gmail.com
Add me to the list of people not happy about this change being slipped in without prominent announcements months in advance. Now I have to scramble to recertify half a dozen servers before I get users complaining.


mathew

kingr...@gmail.com

unread,
Apr 24, 2017, 12:20:43 PM4/24/17
to Security-dev
You guys are killing me with these sudden changes. Don't worry, I didn't already have tons of work to do this week.

sasc...@gmail.com

unread,
Apr 26, 2017, 9:58:10 AM4/26/17
to Security-dev, blin...@chromium.org, rsl...@chromium.org
God...there are days I really believe some browser programmers are so far away from their users and breaks or complicate HTTPS/SSL/TLS stuff in the name "of security" to the worse by for example breaking or hindering SSL scanning / MITM in most ways possible as by enforcing HSTS in the browsers or this unnecessary change to ignore the CN field in favor of SAN even if CN never was declared dead AFAIK.

Same with SSL warnings in a browser in general. Long time ago I liked chrome for it´s simple, logic and intuitive Cert warning approach "red warning page for a certificate issue" with a direct accessible "Proceed" Button shown instead a oversized warning page which has to be expanded everytime to continue to a warned website. This definately is not a security improvement, this is only enforcing people to follow many sequential steps to reach a website instead simply go to a "proceed" button on a red warning page.

Independent of various discussions by some security researchers and/or developers "MITM breaks your security" IS MITM / SSL scanning one of the best ways for companies to protect normal users against their internet usage against every common sense. And I keep that position against all RC4, TLS1.x etc. discussions, which definately have their right to be discussed due security concerns (on a high level). Todays real threats normal users a confronted are malware or sensitive documents slipping through SSL/TLS secured connectios uncontrolled. I personally prefer any "insecure" RC4 cipers for my connection over any "sorry, we do not scan SSL...this breaks the intent of SSL".

Really...real concerns aren´t nation state hackers exploiting broken or compromised cipher suites....todays companies are more hurt by all that crap entering a network via encrypted connections.

And even if HSTS should "improve" security....Yes, I like to MITM services as Google Search and other websites to halfway effectively block advertisments, trackers and data mining companies and all other stuff which concerns me more than those proposed, theoretical "security issues"

Sometimes I also get tempted to think some "enhancements" are not done to improve security, but to keep money flowing by protecting the ability to flood people with advertisements and track every virtual movement with tons of trackers, analytics and user behaviour webservices, which btw. as side effect also namely slows down the whole surfing experience besides the related security concerns...

Also why shouldn´t I trust for internal use more my internal PKI used for MITM in proxies than trusted certification authorities ?

Really....why is no one developing technologies which proactively assists intended MITM, but maybe allows to place an overlay in a browser or a warning sign somewhere in the browser telling the user "this connection is MITM´ed, as the original certificate got replaced", but allows the users to do their work instead making life of admins in the companies difficult by maintaining tons of SSL exclusions and intermittently get hit by new SSL behaviours or issues due "security" changes. In 99% of the MITM cases these are most likely legitimate SSL Proxies used in companies to protect their infrastructure and users, and a small percentage are real attacks maybe used in some public places or "live hacker demos" on some security events....

my very personal 5 cents...

Eran Messeri

unread,
Apr 26, 2017, 10:16:35 AM4/26/17
to sasc...@gmail.com, Security-dev, blin...@chromium.org, Ryan Sleevi
On Wed, Apr 26, 2017 at 2:58 PM, <sasc...@gmail.com> wrote:
God...there are days I really believe some browser programmers are so far away from their users and breaks or complicate HTTPS/SSL/TLS stuff in the name "of security" to the worse by for example breaking or hindering SSL scanning / MITM in most ways possible as by enforcing HSTS in the browsers or this unnecessary change to ignore the CN field in favor of SAN even if CN never was declared dead AFAIK.
It was declared deprecated 17 years ago:

sasc...@gmail.com

unread,
Apr 26, 2017, 10:17:21 AM4/26/17
to Security-dev, blin...@chromium.org, rsl...@chromium.org, sasc...@gmail.com
BTW - small addendum: My previous post wasn´t specifically placed due this concrete or specific thread/announcement - I mixed various contents from the past and my considerations to all those "SSL/TLS" enhancements and general discussions in terms of MITM usage. I generally support the idea to assist MITM instead making it worse to use in a way which still keeps the ability to inform users, that they may get MITM´ed / SSL scanned, but helps especially companies to protect their infrastructure and users against crap passing encrypted connections.

met...@gmail.com

unread,
Apr 26, 2017, 10:18:46 AM4/26/17
to Security-dev, blin...@chromium.org, rsl...@chromium.org, sasc...@gmail.com
It turns out that CentOS 6 and CentOS 7 ship with OpenSSL configured to generate certificates with only CN, no SAN.

Mozilla's reference guide to server side TLS configuration talks a lot about algorithms, but doesn't even mention subjectAltName:
https://wiki.mozilla.org/Security/Server_Side_TLS

The official OpenSSL site seems to have nothing relevant in the documentation:
https://www.google.com/search?sitesearch=www.openssl.org&q=subjectAltName

Microsoft presents it as an extension which can *damage* security and "increase the risk of impersonation attack":
https://technet.microsoft.com/en-us/library/ff625722%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

Given the above and the fact that I'd never seen a single set of instructions for SSL even mention SAN before all our certificates stopped working, I'm betting there are a lot of angry people out there.

Next time, please:
- Evaluate how many people are likely to be affected
- Make prominent public announcements, not on a developer mailing list
- Provide instructions for fixing the problem
- Deprecate, rather than proceeding straight to the "throw up an error page" approach

It should have been handled more like the SHA1 or TLS 1.0 deprecation transitions.


mathew

Ryan Sleevi

unread,
Apr 26, 2017, 10:51:28 AM4/26/17
to met...@gmail.com, Security-dev, blink-dev, Ryan Sleevi, sasc...@gmail.com
On Wed, Apr 26, 2017 at 10:18 AM, <met...@gmail.com> wrote:
It turns out that CentOS 6 and CentOS 7 ship with OpenSSL configured to generate certificates with only CN, no SAN.

OpenSSL is not a tool to be used to generate certificates that are expected to 'just work'. For example, an out of the box OpenSSL on these platforms also uses an invalid string encoding. It is meant to provide a tool and framework for folks to configure appropriately.
 
Mozilla's reference guide to server side TLS configuration talks a lot about algorithms, but doesn't even mention subjectAltName:
https://wiki.mozilla.org/Security/Server_Side_TLS

That's because it's not something server operators need to be aware of, because it's been required of CAs since 2012.
 
The official OpenSSL site seems to have nothing relevant in the documentation:
https://www.google.com/search?sitesearch=www.openssl.org&q=subjectAltName

The difficulty of documentation in OpenSSL is unsurprising, especially as they've significantly reorgnized the site and removed a lot of their excellent documentation.

For what it's worth, the page is https://www.openssl.org/docs/manmaster/man5/x509v3_config.html , which is the official manual page for generating X.509 certificates.
 
Microsoft presents it as an extension which can *damage* security and "increase the risk of impersonation attack":
https://technet.microsoft.com/en-us/library/ff625722%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

To be clear, Microsoft's aptly stating that, on older versions of Windows, it's a security risk to allow clients to automatically enroll (thereby control) the values for the subjectAlternativeName, because the autoenroll system does not validate these names are accurate (unlike what they do for directory names). Subsequent versions of Windows do allow auto-enrollment of SANs, provided they match the FQDN of the enrolling machine. For non-machine enrollment (e.g. end-user), it's also correct that having them generate arbitrary SANs is dangerous - much like allowing the attacker to say "I am google.com". For those cases, they rightfully recommend that you require manual review.

I'm afraid you've misread this documentation, but I can understand that if you're looking to support the view the SAN isn't required, this would seem appealing.
 
Given the above and the fact that I'd never seen a single set of instructions for SSL even mention SAN before all our certificates stopped working, I'm betting there are a lot of angry people out there.

Next time, please:
 - Evaluate how many people are likely to be affected

We did. As you can see on the original announcement, the number of validations affected represent an incredibly small fraction of both users and site operators. It also is exclusively limited to those managing their own PKIs that have not followed the industry standards - as noted, it's been deprecated since HTTPS itself was introduced.
 
 - Make prominent public announcements, not on a developer mailing list

This was tracked on chromestatus.com. It also went out with our Enterprise release notes regularly in advance. There's also the opportunity to run Dev and Beta versions within your organization, to help surface any concerns you might have well before it's launched.
 
 - Provide instructions for fixing the problem

As noted, EnableCommonNameFallbackForLocalAnchors is an enterprise policy to work around this. However, in doing so, you introduce security risks to your organization, and should do so sparingly.
 
 - Deprecate, rather than proceeding straight to the "throw up an error page" approach

What do you believe this means? Particularly, what do you believe this should mean for situations where there is an active security bug?
 
It should have been handled more like the SHA1 or TLS 1.0 deprecation transitions.

Thank you for your feedback. Certainly, I wish we would have phased these out much sooner - as noted on the bug, it was something I've been tracking since 2013 to measure the impact of such a phase out, to make sure we had accurate numbers.

As always, you can help make sure your concerns are surfaced by running earlier versions (Dev, Beta, or Canary), and as an enterprise, opting in to anonymous usage stats to help ensure the impact to your organization is measured. While we always strive to provide ample notice to the ecosystem, it's also worth noting we're not the only one to have deprecated this, and that there are indeed active security issues that arise from continuing to support this. In balacing the risk versus compatibility, the risk (to all Internet users) was much, much greater than the compatibility impact to the limited number of Enterprises, for whom mitigation options were and are provided, and for which communications went out. For enterprise-focused customers, https://enterprise.google.com/chrome/chrome-browser/ can be a one-stop portal for signing up to updates and even support agreements to help measure, evangelize, and minimize any impact to Enterprise-specific use cases.

Ryan Sleevi

unread,
Apr 26, 2017, 11:00:22 AM4/26/17
to sasc...@gmail.com, Security-dev, blink-dev, Ryan Sleevi
On Wed, Apr 26, 2017 at 9:58 AM, <sasc...@gmail.com> wrote:
God...there are days I really believe some browser programmers are so far away from their users and breaks or complicate HTTPS/SSL/TLS stuff in the name "of security" to the worse by for example breaking or hindering SSL scanning / MITM in most ways possible as by enforcing HSTS in the browsers

If you're having issues, it's not related to Chrome policies. https://dev.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters- documents our policies here that apply to both HSTS and HPKP, but errors are not fatal if you're using a properly configured scanning software legitimately installed on a device operated and owned by the Enterprise organization. As long as its your device, and is properly observing the protocol specifications, we aim to minimize impact.
 
or this unnecessary change to ignore the CN field in favor of SAN even if CN never was declared dead AFAIK.

It was declared dead in RFC 2818. Support for commonName allows for bypassing restrictions on certificates in such a way that it's possible to issue a legitimate certificate for any valid domain undetectably, and without consequence, because it's fully conforming to all the valid specifications.

As I'm sure you can understand, allowing arbitrary parties to Internet-wide intercept communication is something we treat as a Very Serious security issue.
 
Same with SSL warnings in a browser in general. Long time ago I liked chrome for it´s simple, logic and intuitive Cert warning approach "red warning page for a certificate issue" with a direct accessible "Proceed" Button shown instead a oversized warning page which has to be expanded everytime to continue to a warned website. This definately is not a security improvement, this is only enforcing people to follow many sequential steps to reach a website instead simply go to a "proceed" button on a red warning page.

Thank you for your feedback. Have you had the opportunity to review the peer-reviewed scientific research that explains these changes, and the process and methodology for making them? It might help explain how this is, from a quantifiable measured perspective, an improvement overall, even if individual opinions may vary. 

You can find just a sampling of these efforts at:


I've refrained from addressing most of your other points, as I think you acknowledge many of them are opinions, and as such, we can reasonably disagree. We see a variety of threats against users, both from inside the organization and from outside, and do our best to provide a browser that can provide security for all users. While understandably, this may occasionally conflict with an individual organizations good, it's a collective health problem in which sometimes the needs to provide a consistent, baseline assurance of security outweighs those of individual organizations who may have the necessary technical skill and sufficiency to operate things in a way that's reasonable for their threat model. That said, I think most of those actively practicing in the field would know the limits of our knowledge and ability, and suggest that this is not realistically possible, but that's simply the result of knowing our limitations, the threats, and the perfect skills required to even get remotely close to that level.

PhistucK

unread,
Apr 26, 2017, 12:31:21 PM4/26/17
to Ryan Sleevi, sasc...@gmail.com, Security-dev, blink-dev
>  It also went out with our Enterprise release notes regularly in advance.
Where can I find those "Enterprise release notes"?
I searched for chrome release notes "commonName" and nothing came up.


PhistucK

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Ryan Sleevi

unread,
Apr 26, 2017, 12:40:08 PM4/26/17
to PhistucK, Ryan Sleevi, Dä Säschu, Security-dev, blink-dev
Sign up at the site I mentioned.

Ryan Sleevi

unread,
Apr 26, 2017, 12:43:35 PM4/26/17
to Ryan Sleevi, PhistucK, Dä Säschu, Security-dev, blink-dev
And it was also captured in https://developers.google.com/web/updates/2017/03/chrome-58-deprecations but it looks like there's a JS error on the page at the moment. I let folks know.

PhistucK

unread,
Apr 26, 2017, 12:44:15 PM4/26/17
to Ryan Sleevi, Dä Säschu, Security-dev, blink-dev
:( Why is there no page, blog or similar for that as well? In order to keep track of the readers and be able to contact them in critical change cases?


PhistucK

Ryan Sleevi

unread,
Apr 26, 2017, 12:46:14 PM4/26/17
to PhistucK, Ryan Sleevi, Dä Säschu, Security-dev, blink-dev
There is https://developers.google.com/web/updates/2017/03/chrome-58-deprecations . The Enterprise notes focus on drawing specific attention to Enterprise-oriented concerns, which I'm sure you can understand aren't useful in a broadly reaching communication. But there was the broad-reaching comms at the Developer site. It just didn't show in the Beta notes.

PhistucK

unread,
Apr 26, 2017, 1:00:59 PM4/26/17
to Ryan Sleevi, Dä Säschu, Security-dev, blink-dev
I do not mind about it not being broad reaching, but a place that keeps all of the release notes of the past releases makes perfect sense to me. For example, say I signed up after the Chrome 58 Enterprise release notes came out (but before it was released to stable), I am going to miss them forever and will be surprised by the breaking changes.
This is actionable. I can delay the installation of Chrome 58 for a short while until I get the breaking changes sorted in the intranet.

It is 2017, not 1997. Archives are very common nowadays.


PhistucK

Eric Lawrence

unread,
Apr 26, 2017, 1:44:28 PM4/26/17
to PhistucK, Ryan Sleevi, Dä Säschu, Security-dev, blink-dev

PhistucK

unread,
Apr 26, 2017, 1:46:07 PM4/26/17
to Eric Lawrence, Ryan Sleevi, Dä Säschu, Security-dev, blink-dev
Yes, I mean the Chrome for Enterprise release notes, not the broad-reaching developer-oriented ones.


PhistucK

feld...@gmail.com

unread,
Apr 26, 2017, 1:54:41 PM4/26/17
to Security-dev, blin...@chromium.org, rsl...@chromium.org
So are you going to patch OpenSSL to make it easier to generate CSRs with SANs then because this is insane and requres zsh? Ask any random sysadmin how to generate SAN CSRs and they'll be googling for an hour.

openssl req -new -newkey rsa:4096 -nodes -sha256 -out ${domain}.csr -keyout ${domain}.key -subj "/C=US/ST=MyState/L=MyCity/O=${company}/CN=${domain}/emailAddress=ab...@example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${domain},DNS:www.${domain}"))

Ryan Sleevi

unread,
Apr 26, 2017, 1:58:00 PM4/26/17
to feld...@gmail.com, Security-dev, blink-dev, Ryan Sleevi
On Wed, Apr 26, 2017 at 1:54 PM, <feld...@gmail.com> wrote:
So are you going to patch OpenSSL to make it easier to generate CSRs with SANs then because this is insane and requres zsh? Ask any random sysadmin how to generate SAN CSRs and they'll be googling for an hour.

openssl req -new -newkey rsa:4096 -nodes -sha256 -out ${domain}.csr -keyout ${domain}.key -subj "/C=US/ST=MyState/L=MyCity/O=${company}/CN=${domain}/emailAddress=ab...@example.com" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${domain},DNS:www.${domain}"))

Hopefully it won't be an hour.

http://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl/27931596#27931596 is one of the top results (linked to the #1 result, but I'm sure linking here will help). 

feld...@gmail.com

unread,
Apr 26, 2017, 2:04:35 PM4/26/17
to Security-dev, feld...@gmail.com, blin...@chromium.org, rsl...@chromium.org
That solution requires editing a config file for each CSR you do. That's absolutely unacceptable.

Alex Gaynor

unread,
Apr 26, 2017, 2:07:58 PM4/26/17
to feld...@gmail.com, Security-dev, blink-dev, rsl...@chromium.org
If you're in a position where you need to create a large number of CSRs, you may want to automate it with something that gives you slightly more control and a more expressive API, to toot my own horn: https://cryptography.io/en/latest/x509/tutorial/

Alex


--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.



--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6

Ryan Sleevi

unread,
Apr 26, 2017, 2:30:14 PM4/26/17
to Alex Gaynor, feld...@gmail.com, Security-dev, blink-dev, Ryan Sleevi
For sure. OpenSSL's config file syntax also fully supports automation of this (whether through the 'req', 'x509', or 'ca' commands). I would hope this discussion doesn't involve too much OpenSSL support, other than highlighting that the OpenSSL manpages have covered ways to simplify this for over a decade. I can understand that when something 'just works', reading the manual isn't often a priority, but inevitably, software marches on as the ecosystem responds to security threats. Luckily, OpenSSL had the foresight even back then to include all the tools necessary.

A brief amount of help - although probably the last I can give to OpenSSL-specific help - the .cnf file supports the syntax ${ENV::variable_name} as a way of doing substitutions. The Chrome Team's build tools use this, for example, to generate a variety of test certificates.

[exts]
subjectAltName=@SAN

[SAN]
DNS.1=${ENV::domain}
DNS.2=www.${ENV::domain}

Would allow you to use your existing ${domain} environment variable.


Note that, for using OpenSSL as a CA, it's generally poor form to rely on /etc/ssl/openssl.cnf. You should think of that as an example 'skeleton' file, and configure appropriate for each individual CA you're running using OpenSSL.

I realize that OpenSSL may not be the best documented example, but this hopefully helps you find better tools to support your needs, gives you a path to read more about the support your chosen tool already has, and gives you alternatives if you wish to simplify your management. "Running" a CA is hard stuff, and running with OpenSSL is likely going to be a continued source of pain "out of the box". Best of luck!

feld...@gmail.com

unread,
Apr 27, 2017, 10:16:32 AM4/27/17
to Security-dev, blin...@chromium.org, rsl...@chromium.org
I have recently been informed this breaks Common Criteria FIA_X509 SFRs which requires that CN matching works on certificates without SAN. This would make Chrome no longer compliant for the federal government. More investigation will be needed as I am still looking for the specific language that defines this requirement.

Hanno Böck

unread,
Apr 27, 2017, 10:30:01 AM4/27/17
to feld...@gmail.com, Security-dev, blin...@chromium.org, rsl...@chromium.org
Hi,
I tried to googl for those criteria, but didn't find them, can you
point to a source? Or are they nonpublic?

Is there any justification for that requirement? Or is it more an
example of gov certifications doing pointless things without a reason?


--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Mark Felder

unread,
Apr 27, 2017, 10:35:56 AM4/27/17
to Hanno Böck, Security-dev, blin...@chromium.org, rsl...@chromium.org
I was informed by an acquaintance who works with this compliance. I
think the details are somewhere on this site, but there are a lot of
PDFs to hunt through.

http://www.commoncriteriaportal.org/cc/

Ryan Sleevi

unread,
Apr 27, 2017, 10:37:55 AM4/27/17
to Hanno Böck, Mark Felder, Security-dev, blink-dev, Ryan Sleevi
On Thu, Apr 27, 2017 at 10:29 AM, Hanno Böck <ha...@hboeck.de> wrote:
Hi,

On Thu, 27 Apr 2017 07:16:32 -0700 (PDT)
feld...@gmail.com wrote:

> I have recently been informed this breaks Common Criteria FIA_X509
> SFRs which requires that CN matching works on certificates without
> SAN. This would make Chrome no longer compliant for the federal
> government. More investigation will be needed as I am still looking
> for the specific language that defines this requirement.

I tried to googl for those criteria, but didn't find them, can you
point to a source? Or are they nonpublic?

Is there any justification for that requirement? Or is it more an
example of gov certifications doing pointless things without a reason?

The current criteria is https://www.niap-ccevs.org/pp/pp_md_v2.0.pdf FCS_TLSC_EXT.2.2 

This does not conflict with this change, but in fact supports it:

FCS_TLSC_EXT.2.2

The TSF shall verify that the presented identifier matches the
reference identifier according to RFC 6125.
Application Note: The rules for verification of identify are described in Section 6 of RFC
6125. The reference identifier is established by the user (e.g. entering a URL into a web
browser or clicking a link), by configuration (e.g. configuring the name of a mail server or
authentication server), or by an application (e.g. a parameter of an API) depending on the
application service. Based on a singular reference identifier’s source domain and application
service type (e.g. HTTP, SIP, LDAP), the client establishes all reference identifiers which are
acceptable, such as a Common Name for the Subject Name field of the certificate and a
(case-insensitive) DNS name, URI name, and Service Name for the Subject Alternative
Name field. The client then compares this list of all acceptable reference identifiers to the
presented identifiers in the TLS server’s certificate.
The preferred method for verification is the Subject Alternative Name using DNS names,
URI names, or Service Names. Verification using the Common Name is required for the
purposes of backwards compatibility. Additionally, support for use of IP addresses in the
Subject Name or Subject Alternative name is discouraged as against best practices but may
be implemented. Finally, the client should avoid constructing reference identifiers using
wildcards. However, if the presented identifiers include wildcards, the client must follow the
best practices regarding matching; these best practices are captured in the assurance activity.

Mark Felder

unread,
Apr 27, 2017, 10:50:00 AM4/27/17
to Ryan Sleevi, Hanno Böck, Security-dev, blink-dev
Ok, so this policy demands that verification has to happen, period. It
would not be in compliance to use software that doesn't actually
verify the name on the certificate matches. This is good.

> Verification using the Common Name is required for the purposes of backwards compatibility.

I interpret this as requiring that Common Name has to work, but they
prefer SAN. Chrome isn't removing the ability to match names via
CommonName which would create a vulnerability, but are denying
validation of certificates that use CommonName (unless extra setting
for local trust anchors). Is this still within compliance if they are
explicitly requiring the backwards compatibility? I wonder what an
auditor would say because I can see it both ways.

Ryan Sleevi

unread,
Apr 27, 2017, 10:55:48 AM4/27/17
to Mark Felder, Ryan Sleevi, Hanno Böck, Security-dev, blink-dev
On Thu, Apr 27, 2017 at 10:49 AM, Mark Felder <feld...@gmail.com> wrote:
Ok, so this policy demands that verification has to happen, period. It
would not be in compliance to use software that doesn't actually
verify the name on the certificate matches. This is good.

> Verification using the Common Name is required for the purposes of backwards compatibility.

I interpret this as requiring that Common Name has to work, but they
prefer SAN. Chrome isn't removing the ability to match names via
CommonName which would create a vulnerability, but are denying
validation of certificates that use CommonName (unless extra setting
for local trust anchors). Is this still within compliance if they are
explicitly requiring the backwards compatibility? I wonder what an
auditor would say because I can see it both ways.

Chrome is not audited to that Common Criteria Profile. However, Chrome will work with servers that need to support clients that are audited to that profile.

To be clear, by supporting Common Name as specified by that profile, it will allow bypassing the use of nameConstraints in a way that a nameConstrained sub-CA will be able to have unconstrained issuance. This is, among other reasons, why Common Name has been deprecated since RFC 2818.

As the profiles are routinely updated to respond to emergent security threats, I'm sure that clearer documentation of these risks, such as those provided by https://nameconstraints.bettertls.com , can better inform.

jac...@gmail.com

unread,
May 4, 2017, 3:41:08 PM5/4/17
to Security-dev, feld...@gmail.com, rsl...@chromium.org, ha...@hboeck.de, blin...@chromium.org
Ryan, & Mark,

I believe you will find that any auditor will find that Chrome is no longer compliant for use in the Federal Government. Basically, the CCP says what RFC2818 says says but deprecates:
A cert if valid if it matches the cert name or a name in a SAN.
IF (and only if) the SAN is blank, then the cert CN MUST be checked for a match.

RFC2818 says that the IFF portion is deprecated, but it still MUST be done. CCP does not mention the deprecation at all. Thus, the fact that Chrome 58+ no longer considers a cert valid in the case that there is not a match in the name and the SAN is blank. It does NOT follow the "If SAN is blank, you MUST consider the CN". Thus, it is no longer CCP compliant.

Just a strict reading of RFC2818 and CCP. Not judging any of the security merits of doing / not doing CN checking.

PhistucK

unread,
May 4, 2017, 4:07:18 PM5/4/17
to jac...@gmail.com, Security-dev, feld...@gmail.com, Ryan Sleevi, Hanno Böck, blink-dev
Ryan already stated -
> Chrome is not audited to that Common Criteria Profile

So this is apparently not a goal of Chrome at the moment anyway. If it were compliant in the past, it was apparently coincidental.


PhistucK

iup...@gmail.com

unread,
May 18, 2017, 1:48:11 PM5/18/17
to Security-dev, bhu...@gmail.com, blin...@chromium.org, rsl...@chromium.org
On Friday, 3 February 2017 11:05:55 UTC-5, Adam Langley wrote:
> On Thu, Feb 2, 2017 at 9:37 PM, <bhu...@gmail.com> wrote:
> We use our MS CA for other non AD integrated applications, and we actually have the subjectAltName field disabled for any certificates that are only authenticating one domain, user, device, etc. and only have the Common Name field to verify against.
>
>
>
> There may be others in this situation as Microsoft actually recommends disabling the SubectAltName field, see this link https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx
>
>
> The document merely notes that SANs need to be carefully reviewed because they specify who a certificate is being issued for. However, if you only use commonNames then you already have to review those names to the same standard. Like many other extension fields, the SAN is sensitive and MS are right to highlight that, but there's no argument there for continuing to wedge hostnames into CN.
>
>
>
>
> Cheers
>
>
> AGL

Microsoft says just above that "the use of user-defined SANs can increase the risk of impersonation attacks".

As a sysadmin in an IT department where we use AD CS for internal applications and sites, this is a major pain. The certificates, while issued by AD CS, are for various other platforms that don't integrate with AD.

It will be easier for me to tell our users to use another browser rather than make all these application changes.

IT departments are staffed with minimal personnel, and issues like this will be deferred/deflected/etc. as much as possible.

phydr...@gmail.com

unread,
Sep 26, 2017, 1:47:26 PM9/26/17
to Security-dev, bhu...@gmail.com, blin...@chromium.org, rsl...@chromium.org
If anybody can outline an attack against either a valid common name when a SAN is present or attack when it is not present i'd be interested.

On Friday, February 3, 2017 at 12:04:08 AM UTC-7, PhistucK wrote:
> :S
> So who is right? Microsoft sort of says that only using commonName prevents impersonation attacks and this intent says it is sort of the other way around. :(
>
>
>
>
>
>
>
> ☆PhistucK
>
>
> On Fri, Feb 3, 2017 at 7:37 AM, <bhu...@gmail.com> wrote:
> On Friday, 27 January 2017 19:45:39 UTC-5, Ryan Sleevi  wrote:
>
> > Primary eng (and PM) emails
>
> > rsl...@chromium.org awha...@chromium.org
>
> >
>
> >
>
> > Link to "Intent to Deprecate" thread
>
> > No deprecate thread; it's been deprecated since HTTPS was first introduced (RFC 2818) in 2000.
>
> >
>
> >
>
> > Summary
>
> > Certificates have two ways to express the domain/IP they're bound to - one which is unstructured and ambiguous (commonName), and one which is well-defined (subjectAltName). In the absence of any subjectAltNames, Chrome currently falls back to comparing the domain against the commonName, if present.
>
> >
>
> >
>
> > This proposal is to remove that fallback path; in effect, requiring a subjectAltName. Ideally, we would do this for all certificates (publicly trusted and privately trusted), but if there are concerns about compat risk, we can restrict it to publicly trusted certificates.
>
> >
>
> >
>
> > Motivation
>
> > Since 1997 (X.509v3's ratification), certificates have had two ways to express a binding to a domain name - either via the commonName attribute within the certificate's subject, or via the explicitly typed (dNSName or iPAddress) of the SubjectAlternativeName Extension.
>
> >
>
> >
>
> > Since RFC 2818 (published in 2000, first drafted in January 1998), the use of the commonName field has been considered deprecated, because it's ambiguous and untyped - that is, it might contain a human-readable name or it might be a domain name.
>
> >
>
> >
>
> > The use of the subjectAlternativeName fields leaves it unambiguous whether a certificate is expressing a binding to an IP address or a domain name, and is fully defined in terms of its interaction with Name Constraints. commonName, however, is ambiguous, and because of this, support for the commonName has been a source of security bugs - in both Chrome and the libraries it uses and within the TLS ecosystem at large.
>
> >
>
> >
>
> > Compatibility Risk
>
> > Low. RFC 2818 has deprecated this for nearly two decades, and the Baseline Requirements (which all publicly trusted CAs must abide by) has required the presence of a subjectAltName since 2012.
>
> >
>
> >
>
> > Mozilla Firefox already requires the subjectAltName for any newly issued publicly trusted certificates since Firefox 48 ( https://bugzilla.mozilla.org/show_bug.cgi?id=1245280 ).
>
> >
>
> >
>
> > Usage information
>
> > From a metrics perspective, less than .002% of publicly trusted certificate validations would require this behaviour (Net.CertCommonNameFallback minus Net.CertCommonNameFallbackPrivateCA).
>
> >
>
> >
>
> > As 1.57% of privately-trusted CA certificates rely on this behaviour (or 0.1% of all certificate validations), it may be premature to deprecate it for privately-trusted CAs; alternatively, we could remove it with an enterprise policy to allow it for a limited number of releases. Unfortunately, despite being deprecated for nearly 20 years, it's unlikely we'd be able to drive this number down (and improve the security of the ecosystem) without taking further action.
>
> >
>
> >
>
> > OWP launch tracking bug
>
> > https://bugs.chromium.org/p/chromium/issues/detail?id=308330
>
> >
>
> >
>
> >
>
> > Entry on the feature dashboard
>
> > https://www.chromestatus.com/feature/4981025180483584 (Apologies if I botched this; not sure how to capture "The standard says this is deprecated, and Mozilla supports deprecating")
>
>
>
> We use our MS CA for other non AD integrated applications, and we actually have the subjectAltName field disabled for any certificates that are only authenticating one domain, user, device, etc. and only have the Common Name field to verify against.
>
>
>
> There may be others in this situation as Microsoft actually recommends disabling the SubectAltName field, see this link https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx
>
>
>
> Nathan
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "Security-dev" group.
>
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Ryan Sleevi

unread,
Sep 26, 2017, 8:50:44 PM9/26/17
to phydr...@gmail.com, Security-dev, Nathan Allen, blink-dev, Ryan Sleevi
Reply all
Reply to author
Forward
0 new messages