<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 16, 2016 at 7:52 PM, Wayne Thayer <span dir="ltr"><<a href="mailto:wthayer@godaddy.com" target="_blank">wthayer@godaddy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p><span style="font-size:12pt">Does this mean a 'certificate containing an IP address in the CN and only that same IP address encoded as IPAddress in the first SAN entry?' In addition, does it imply:</span><br></p>
<p>- no other SAN entries will be recognized, due to a different compatibility issue (Firefox?)</p></div></div></blockquote><div>I'm not sure why you mentioned Firefox. </div><div><br></div><div>The compatibility issue is simple, and goes back to both RFC 2818 / RFC 6125 - when a sAN of dNSName is present, the commonName should be ignored. If a sAN of dNSName is present, even Windows will ignore the commonName.</div><div><br></div><div>(There were several buggy implementations that did not follow this strictly, but I would hardly find it acceptable for a CA to propose to exploit those security vulnerabilities to sell certificates)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif"><p>- The cert can only support a single IP (only a single CN is allowed)</p></div></div></blockquote><div>It can only support a single IP *for those Windows systems*. Other platforms will support multiple iPAddress SANs, as does Windows 10.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>- Can't deprecate CN as long as this workaround is required</p></div></div></blockquote><div>Define "required". It relies on exploiting not just a lack of functionality, but one with known security vulnerabilities. It could equally be argued that such certificates shouldn't be supported - that we shouldn't be encouraging the issuance of certificates that rely on buggy behaviour.</div></div></div></div>