<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Feb 2, 2016, at 10:06 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:<br class=""><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 2, 2016 at 4:20 AM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzbowen@gmail.com" target="_blank" class="">pzbowen@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br class="">
</span>Do they do this in the presence of a SAN extension or just the absence?<br class=""></blockquote><div class=""><br class=""></div><div class="">Modern browsers: Only when the SAN is bereft of DNS/IP addresses</div><div class="">Most every other software library: In addition to, and generally as the first match. I have seen code (and filed bugs) against implementations in PHP, Python, Ruby, and C that all opted to check CN, and if CN didn't match, check SAN. I've pointed them to RFC 6125 and explained the risks.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> If so, are we anywhere near the point where<br class="">
>> they could stop doing this?<br class="">
><br class="">
> Well, we mandated that SANs should mirror CN quite a while back, so<br class="">
> there may be scope for this soon for publicly-trusted certs. I believe<br class="">
> Ryan had some views here...<br class=""></span></blockquote><div class=""><br class=""></div><div class="">Modern browsers: If they're willing to break the certs issued by some CAs that had 5-10 year validities right before the BRs came into effect, it should be reasonably accomplishable. However, this can *only* be accomplished if browsers recognize the distinction between "Chains to a BR compliant CA" and "Chains to a non-BR compliant CA" (e.g. enterprise CA). The former category should be mostly safe for CNs, save for the long-lived zombie certs. The latter category is dominated by CNs w/o SANs.</div><div class=""><br class=""></div><div class="">Other software: It will be a decade+ before such applications stop checking CNs.</div></div></div></div></div></blockquote><br class=""></div><div>And it is certs like <a href="https://crt.sh/?id=11880495" class="">https://crt.sh/?id=11880495</a> that prove that this is true. That certificate was issued in the last month, has no SAN or EKU, has a FQDN in the CN, and chains back to one or more roots trusted by every browser (<a href="https://gist.github.com/pzb/c55a802c283c7b44002d" class="">https://gist.github.com/pzb/c55a802c283c7b44002d</a>). <a href="https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil" class="">https://www.ssllabs.com/ssltest/analyze.html?d=aflsa.jag.af.mil</a> shows that the certificate is in use at the FQDN in the CN.</div><div><br class=""></div><div>According to the ssllabs analysis, the chain should fail due to policy constraints, but I’m not sure if anything enforces such constraints.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div><div><br class=""></div><div><br class=""></div><br class=""></body></html>