First off, my hat is off and kudos to Internet Security Research Group (ISRG) / letsencrypt.org for bringing some sanity to the encryption certificate aspect of the web, Thank You.
I recognize the posts topic is policy and political. Technically it looks like the code already exists in boulder (if I am wrong about that, point at any references and I would gladly work up and propose patches for review and test) and obviously it was intended in the specification (rfc5280).
This is not a request for ip in field type DNS, that goes against the rfc.
This is not a request for ip in the CN.
This is not a request for an ip only cert.
This is a request to allow and verify subject alternate names of type ipAddress when the name, returned by a domain name server (DNS) query in a resource record (RR) type PTR for the ip address (reverse lookup), matches the requested certificate top level domain name (TLD) and or fully qualified domain name (FQDN) , where both name and ip are present and intended to be included in the certificate being requested (CSR SAN field type IP).
I ask for this because a site that has multiple ip addresses provided by different internet service providers (multi homed) has no other usable method available to allow the user to select the best connection for that user except to form an initial connection to the preferred ip address. This establishes the users preferred route which is cached by the users browser and the browser will continue to use. This does have significant impact on web applications that interact in real time with real world activities.
I believe the rational utilized to restrict (recommend that) a certification authority (CA) not issue a certificate where the subject alternate name of an x.509 v3 certificate contains a field type ipAddress is based on fud.
1) implies that operating systems are affected yet only one browser on those operating systems is known to be negatively impacted (two other browsers when used on these operating systems handle this issue without problem).
2) the affected browser does not fail when the certificate is accessed using the FQDN (the presence of the ipAddress in the SAN does not cause failure) only when the browser attempts to access the cert via the ip address does that browser fail to acknowledge the valid certificate (the browser does not crash).
3) there is a work around available (configuration of the browser) that does not involve misuse of the DNS field type of the CSR SAN .
4) the topic is dated, this has been known for over 5 years. Any intent to resolve the issue by the software vendor has had ample opportunity.
5) the statement of requirement is that a certificate authority (CA) not publish a cert with an ip address in the SAN field type dNSName (last line on the page and poorly written, in part why I claim FUD)
it is curious that the recommendation was not allowed into the published rules, it sits as a linked page randomly floating without identifying authority nor with expectation of expiration, just a random roadblock placed in there for one browser which the page itself denotes as legacy software.
does explicitly acknowledge as defined that an ip address is appropriately present in the subject alternative name (page 35). (the rfc 6818 update does not appear to change this)
almost advocates the use thereof, and certainly does not conflict with
(almost a clone of the baseline) , nor
which is Very vague on the topic
If it is actually the intent of ISRG / letsencrypt.org to "never allow" the use of SAN field type ipAddress, it really should be stated as such in one of the above mentioned documents (CP/CPS). I did read everywhere I thought might contain a clue in this regard before I started crafting this post. The cabforum.org reference is the only item I found (posted on the community.letsencrypt.org pages, thank you for that).
The legacy product referred to on the cabforum.org page is the browser not the operating system, other browsers available for these operating systems work fine
by the way, that one is dated 2011 and conveniently there is no date on
The concerned product does not fail when the browser is pointed at the domain name, only when referencing the ip address.
The defect has been known for a long long time, a google search for "microsoft subject alternative name ipAddress" will share reports from 2011 (over 5 years ago) that describe the problem and offer solutions in the configuration of the browser that will work for ipv4 (but not ipv6, interesting)
Those individuals that are using legacy microsoft product are having no trouble with the self signed root and daily cert that I have been providing for our sites users for the past ten(10) years, I have all of the ip addresses incorporated in the subject alternate name.
Any security conscience enity will not be using legacy microsoft product.
Qualifying the authority to use a ip address is available through the domain name service PTR resource record , any site that needs to have an ip address in a certificate probably has enough knowledge to get a PTR record pointing at the same fully qualified domain name as is being requested for the certificate (CN) or at least the same TLD with the FQDN present in the SAN.
section 220.127.116.11. Authentication for an IP Address
explains about the same thing in pretty plain language
Why this is an issue for me:
I work with web application software that provides user interaction with real world events in real time, latency from every source is an issue (yes, I staple OCSP)
The certificate handshake of a client browser with a https server occurs prior to any configuration control (name rewrite / redirect) by the site/server owner.
A site owner has little control over route selection; the site may provide direct connection to more then one internet service provider (multi homed) but cannot directly advertise this routing information to a client browser, the only method to advertise the existance of multiple ip addresses is through the domain name server providing a "round robin" selected ip address solution.
When the subject alternate name provides acknowledgement of the available ip addresses , the client browser's user can point the browser at an ip address , conduct the certificate handshake then allow the sites https server to coordinate naming convention, allowing the browsers cached ip address and associated route to provide the anticipated level of service.
If we believe the polls (searched: "browser market share", July 2017), less then 3% of the browsers used in the wild will not be able to take advantage of this technique and will be stuck with a round robin / hit or miss route.
Removing the ip address from the subject alternate name causes 100% of the browsers to fail the certificate handshake leaving degraded service as the only alternative.
One alternative method to allow access to the web server where selection of the ip address is done by name would be to list each ip as a uniquely named host, that would lead to the TLD being referenced as a CNAME. This would probably work for letsencrypt but would be an absolute failure for smtp/email. And no, promoting one of these internet service providers as a primary service provider (assignning TLD to that ip) causes problems of its own, as simple as google claiming duplicate content and the inability to refer to the site as a whole.
Please consider enabling the ability to follow the spec and allow placing the reverse path in the cert.
P.S. This may also offer some temporary relief and alternatives for those fighting with ipv6 related accessability issues.