TLS certificate management on Android [LWN.net]

TLS certificate management on Android

Posted Mar 3, 2016 5:59 UTC (Thu) by ptman (subscriber, #57271)
Parent article: TLS certificate management on Android

One reasonable, IMHO, suggestion was to remove the warning for CA certificates that limit their scope. E.g. "nameConstraints=permitted;DNS:example.com" to limit the CA to only signing certificates ending in example.com.

to post comments

TLS certificate management on Android

Posted Mar 3, 2016 6:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

That might lead to... to... gasp... delegation!

Just imagine every mom&pop company paying only ONCE to get *.momandpopcompany.com certifcate and signing THEIR OWN!!! third-level certificates instead of going through Established CA Authorities.

That can't be let to stand. Nope.

TLS certificate management on Android

Posted Mar 3, 2016 10:38 UTC (Thu) by anselm (subscriber, #2796) [Link] (3 responses)

The Established CA Authorities will presumably continue charging an arm and a leg for certificates that have the required flags set to act as a sub-CA, so it's probably not a real problem as far as they are concerned.

TLS certificate management on Android

Posted Mar 3, 2016 20:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

You can't charge too much - there's going to be a race to the bottom. And really lucrative clients like ebay.com or amazon.com will easily pay any amount of money for it.

TLS certificate management on Android

Posted Mar 6, 2016 20:35 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (1 responses)

Amazon is already cross-signed and is seeking independent inclusion in major trust stores (e.g. Mozilla) because they want their Amazon Web Service product to have a one button SSL service of the sort you get for free on a cheap virtual host these days but they don't (quite reasonably) want to pay an existing for-profit CA to issue those certs. So Amazon can issue a million certs tomorrow across the entire namespace, they wouldn't want a delegation.

The "delegation" pipe dream is just that. Today, in 2016, there are brand new SSL certificates being minted that still don't use the correct method to indicate which DNS names the certificate is for, but instead rely on bug compatibility between major browsers to "get away" with continuing to do things the way they did with Netscape Navigator (remember that?)

Huge parts of the x509 certificate spec are written off as unsuitable for any purpose for years and probably decades to come because either incompetently written software was allowed to spread into the wild that relies on nobody using that part of the spec, or, perhaps even worse, Certification Authorities (who are supposed to be experts) signed certs that mis-used those parts of the spec and which don't expire for many years. Delegation is one of those parts. I thought it sounded like a brilliant idea when I first heard about it, but it can't work for probably a decade or more after we get CAs to treat it as real, and we're nowhere near even that. Nobody wants to fight with them about something we probably will never get to see any use out of anyway.

TLS certificate management on Android

Posted Mar 6, 2016 21:25 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> So Amazon can issue a million certs tomorrow across the entire namespace, they wouldn't want a delegation.
I should have been more clear - large companies need a lot of certificates for internal purposes and for user-facing services.

AWS already has one-click SSL for load-balancers.

> The "delegation" pipe dream is just that... Huge parts of the x509 certificate spec are written off as unsuitable for any purpose
The problem is not that parts of X509 are not accessible, but that it's a freaking mess. And TLS is a doubly freaking mess.

Writing a fully conformant TLS stack with all the options supported is pretty much impossible. We're still getting bugs discovered in the spec itself (all those downgrade attacks).

The correct course of action would be designing a completely new infrastructure, that can utilize advances like DNSSEC from the start. It's a pipe dream, but still....

TLS certificate management on Android

Posted Mar 3, 2016 11:30 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (37 responses)

Completely useless for people who use certificates to talk to proxies, since the proxy will proxify anything on the internet.

Of course they only do that because the browser devs refuse to define a secure proxy protocol, with the same security circus scary warnings the article complains of, that do not solve anything but feel good to their issuer.

You're not supposed to proxyfy Google or check the certs your phone accepts, you're here to consume the content Google felt is good for its bottom line.

TLS certificate management on Android

Posted Mar 3, 2016 15:44 UTC (Thu) by josh (subscriber, #17465) [Link] (36 responses)

> the browser devs refuse to define a secure proxy protocol

There is a secure proxy protocol already: it gives you a channel to port 443 on a remote server over which you can do HTTPS to get real security. A bit silly compared to a direct connection, but *shrug*. What browser developers refuse to support is an *insecure* proxy protocol that allows MITM of HTTPS connections.

TLS certificate management on Android

Posted Mar 3, 2016 16:11 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (35 responses)

So :

1. Where is the RFC ?
2. What browsers actually implement it ?
3. How do users authentify to the proxy ?
4. What happens when proxy auth expires while the user is browsing an HTTPS website ? Will the browser renew auth to continue browsing ?

TLS certificate management on Android

Posted Mar 3, 2016 16:33 UTC (Thu) by josh (subscriber, #17465) [Link] (34 responses)

CONNECT is covered in a few places:

https://tools.ietf.org/html/rfc2616#section-9.9

https://tools.ietf.org/html/rfc2616#ref-44

http://tools.ietf.org/html/draft-luotonen-web-proxy-tunne...

Possibly others I'm not familiar with, as well. Every major browser implements that, as do most HTTP libraries and command-line software.

I don't know where proxy authentication (username/password or similar) is documented or how good the handling of that is in browsers and libraries. But that's a separate issue from certificate handling for the site on the other side of the proxy.

TLS certificate management on Android

Posted Mar 3, 2016 19:05 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (33 responses)

Well the answer is, it's not good, it's not even bad, it's inexistent.

Which is why anyone who actually tries to run a proxy, injects a new CA root in the browser. Just to bypass the horrific browser TLS mess, which is more concerned with telling you how bad you are (in typical dilbertian information preventer mode), than actually helping you to connect securely to the proxy you chose to use.

So please do not pretend there are other solutions unless you've actually tried them with success.

TLS certificate management on Android

Posted Mar 3, 2016 19:35 UTC (Thu) by josh (subscriber, #17465) [Link] (32 responses)

CA roots are a *completely* different topic. You should not need a CA root just to run a proxy, unless that proxy is MITMing traffic.

And it's the browser's job to tell you that your network is making your connection insecure. It's more important to protect the majority of Internet users than to make life easier for corporate IT administrators trying to do things they shouldn't.

corporate IT administrators

Posted Mar 6, 2016 23:15 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (30 responses)

As an example of those "corporate IT administrators" I give you the example of an internationally famous FTSE 100 Company which uses the McAfee Web Gateway to MITM proxy all its employees.

Out of the box, the McAfee Web Gateway's built-in CA certificate (used to sign certificates pretending to be Google, Amazon, LWN, HSBC, the British Government and so on) is of course not trusted by anybody. But you can force every corporate computer to add this CA cert to its trust store and so that's what this FTSE 100 Company have done. That way you shut up all the anti-MITM features. In fact (contrary to what you might expect if you believed Nim-Nim's rants) browser vendors go out of their way to allow this to work, because corporates insist upon it.

Having this single point of failure in your security infrastructure isn't a good idea, but in principle it /could/ work and not be that much more dangerous than not having the MITM proxy. There's really only one problem. McAfee Web Gateway isn't a custom solution developed for that one FTSE 100 Company, it's a commercial product, anybody can buy one (under a variety of names, the core software is the same). So the effect of adding "McAfee Web Gateway" to a computer's trust store is to allow anybody who has purchased the product, or who has obtained the private key from a legitimate purchaser's product, to impersonate literally any SSL site to all employees of the FTSE 100 Company.

To be fair to them, Intel / McAfee do document this problem in the product manual, and doubtless if any actual smart, security-minded people were buying MITM proxies they'd ask "So, how do we attach this to the HSM we use as a responsible corporation to do our PKI?" and have it all explained. But the average corporate IT administrator at a non-software company (even with a multi-billion dollar market cap) is happy that they spent a five figure sum of money on "securing web access" and they can check that off their Information Security checklist. If you explain to them that actually they've completely undermined a crucial element of the security infrastructure they'd be dumbfounded, they paid thousands of dollars, how can that not mean their security is better ?

corporate IT administrators

Posted Mar 7, 2016 13:04 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (29 responses)

Some more disinformation

What corporates insist on is a way to hook browsers on their security gateways (aka proxies). Because they feel the cost of an intrusion is such the pain of those security gateways is more than worth it. And they actually trust their security provider more than any random website (surprise).

Browser authors, on the other hand, refuse to make their products work properly with those equipments except by adding a root CA to the trust store (tialaramex's § 2). And complain all year round how horrific this solution is (tialaramex's § 3 and 4). And offer vaporous alternatives that never actually solve anything when you take 5s to actually consider them¹.

Well, no corporate is in love with the technical solution either, and they'd drop it in a blink if something else was available.

But browser people do *not* make something else available. Because that would allow anyone to delegate the security of their accesses to the entity they, *not* the browser authors, chose. And freedom (when it means making your mind without browser "help"), is badforyourhealth®.

So they intentionally perpetuate an horrific technical solution, that forces impersonating websites, and forces disabling browser TLS checks, so they can attack it from a technical POW. And avoid stating plainly they want to keep their lock on HTTPS accesses. And refuse to help their users delegate the security of accesses to something else than browsers. They will happily relay your traffic right and left (pocket, google ad platforms, etc), but god forbid *you* chose to relay it to the security equipment *you* selected and paid for.

*None* of it is an actual technical requirement. Separating the proxy TLS checks from the browser TLS checks is not rocket science (just put proxy negotiation outside the website http headers). But no one can do it without browser cooperation. And browser people are happy to keep the statu quo ante. And harass proxy users. And complain of CAs that impersonate third parties.

¹ Case in point, you can add all the HSMs you want, browser behaviour will still force you to import the CA and make it impersonate Google & friends to make the proxy work, and they will still crucify you for this impersonation, and still FUD about the un-trustliness of the CA owner.

corporate IT administrators

Posted Mar 7, 2016 16:29 UTC (Mon) by josh (subscriber, #17465) [Link] (13 responses)

I don't see anything wrong with making it possible to trust a proxy's certificate separate from that of the traffic passing through the proxy; that seems like a good thing. That would secure traffic to the proxy itself, which does seem useful if authenticating to the proxy. But I don't think browsers should do *anything* to make it easier to MITM HTTPS traffic; no matter the path to the proxy, the proxy itself should continue using CONNECT or similar to pass through HTTPS traffic unmodified.

If anything, browsers need to make MITM attacks harder: when they see a site with a pinned certificate using a different certificate that's in the browser trust store, they should make that MITM visible to the user.

This isn't about browsers ceding their own control; this is about browsers keeping the user safe and in control.

For that matter, browsers have a long history of targeting the end user, not the corporate IT department; many people have fond memories of installing Firefox (or Mozilla before that) on systems that were "supposed" to run IE.

corporate IT administrators

Posted Mar 7, 2016 16:43 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (4 responses)

If you want to make sure your malware proxy is not modifying traffic you need integrity, ie digital signatures. Hiding the traffic from the malware checker defeats its purpose.

corporate IT administrators

Posted Mar 7, 2016 19:22 UTC (Mon) by josh (subscriber, #17465) [Link] (3 responses)

That's an interesting concept that I haven't seen brought up in such discussions before. While I'd still never want to use such a network myself, it'd certainly be *interesting* to have a protocol that could support integrity protection that prevents MITM modification, while still allowing monitoring. That could be useful in an environment with regulatory compliance issues, and it'd be somewhat less problematic than allowing MITM.

That said, while such an approach might get some of the existing IT departments running MITM proxies to switch, it might also get IT departments that currently *don't* break HTTPS to try to use that interception mechanism when they would otherwise have had no such option. So I'm not entirely convinced that such an option would be a net positive.

corporate IT administrators

Posted Mar 8, 2016 2:17 UTC (Tue) by flussence (guest, #85566) [Link] (2 responses)

>While I'd still never want to use such a network myself, it'd certainly be *interesting* to have a protocol that could support integrity protection that prevents MITM modification, while still allowing monitoring.

SSL/TLS itself is already capable of that: the command `openssl ciphers -v 'eNULL:!aNULL'` will give you a list of cipher suites (including one in TLS 1.2) which send the data in clear text but cryptographically signed. Naturally, this won't work in a browser.

corporate IT administrators

Posted Mar 8, 2016 6:12 UTC (Tue) by josh (subscriber, #17465) [Link] (1 responses)

That would make it cleartext end-to-end, rather than encrypted from the site to the proxy and the proxy to the browser, and only cleartext-with-integrity-protection to the proxy itself.

corporate IT administrators

Posted Mar 8, 2016 17:59 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

It should still be possible to implement cleartext-with-integrity-protection without changing TLS per se, though you would need an out-of-band protocol for communication between the client and the proxy. The client just needs to give the proxy the decryption key which it derives from the DH master secret. If it keeps the corresponding HMAC secret to itself then the proxy can decrypt the traffic, but not tamper with it; end-to-end authenticity would thus be preserved.

corporate IT administrators

Posted Mar 8, 2016 16:26 UTC (Tue) by raven667 (subscriber, #5198) [Link] (5 responses)

> But I don't think browsers should do *anything* to make it easier to MITM HTTPS traffic; no matter the path to the proxy, the proxy itself should continue using CONNECT or similar to pass through HTTPS traffic unmodified.

The purpose of the proxy is to inspect the cleartext to block malware, or network usage that violates the policy of the owner, when the same administrative entity owns the network and edge equipment. The problem is that anything which makes it easier to MITM for legitimate security reasons, also can be used by bad actors to transparently intercept traffic in ways that are difficult to detect for the average person. The browser vendors are making the policy decision that protecting people from repressive governments or criminal organizations is more important than enabling inspection by admin policy.

corporate IT administrators

Posted Mar 8, 2016 18:01 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (4 responses)

Actually, they're not protecting anyone. It's easier to grandstand publicly than actually cut proxies and deal with the backlash of all their users. So they end up supporting the worst kind of MITM officiously, instead of working to make it as safe as possible and under user control.

And yes like any useful tech it can be used for evil purposes. Let's kill mail to put an end to spammers.

corporate IT administrators

Posted Mar 8, 2016 18:38 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> Actually, they're not protecting anyone. It's easier to grandstand publicly than actually

If you can't even understand or acknowledge the perspective of the people you are arguing with, how do you expect to effectively communicate your point? Changing minds requires a dialog not a monologue.

corporate IT administrators

Posted Mar 8, 2016 22:19 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (2 responses)

I'm sorry, but what exactly are you taking offense at?

Did I write anything but the truth?

Am I wrong when I state that despite vehement public opposition to the idea, browser people make sure year after year that it is possible to MITM connexions by importing CAs in their certificate stores? That is a fact and easily checked by consulting browser changelogs.

Am I wrong when I state that making standard communication with proxies obsolete, by refusing to overhaul it with the rest of the web stack, only pushed corporations and security providers to convert massively to the worst and most dangerous kind of MITM? Who targets anything else nowadays?

Am I wrong when I state the people browsers claim to "protect", actually use the tech browsers want to ban (proxies), to protect themselves (for example to bypass the great firewall of China)? That this technology is by no means as one-sided as the browser discourse wants you to believe?

Am I wrong when I state that refusing to give browser users the interfaces to check whom they are giving access to, only results in having this access taken without control?

What, exactly, is accomplished by continuing to push for an ideal state, while enabling its exact reverse year after year, since society is not ready for this ideal state today (will it ever be?) Would it be such a defeat to give browser users a middle ground solution now, instead of waiting for a complete victory that refused to happen for at least a decade?

And, BTW, I do not mean ideal in the positive sense. I mean ideal in the imaginary sense. We've left the point, when one could imagine connecting to the Internet, without firewalls and other security tools, a long time ago. Refusing to secure the network, because browsers have their own security, is irresponsible (first, all connexions are not made via browsers, and second, even if they were, why should we trust browsers absolutely?)

corporate IT administrators

Posted Mar 9, 2016 1:57 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

I wsnt taking any offence, I was providing advice on how to better communicate your point, which you seem to have completely missed, and kind of underlines what I was saying.

corporate IT administrators

Posted Mar 9, 2016 18:33 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Please realise, that taking the higher moral ground ("protecting people from repressive governments or criminal organizations") while refusing to discuss facts that contradict this manichean view, is highly inflammatory in itself.

corporate IT administrators

Posted Mar 9, 2016 16:46 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

> browsers need to make MITM attacks harder

I actually wanted to take another stab at this one, if the same entity owns the network, proxy and end-point host then they aren't a MITM, they are the owner, so funneling all traffic through a proxy to inspect the clear text is _not_ a MITM attack, it's a way for the owner of the machine to centralize security policy rather than requiring a plugin or extension to be run on every instance of the browser.

This kind of thing is only a problem when the middle box and end-point host are not owned by the same entity, in the case of a network allowing guest access or an ISP these kinds of technologies would be highly unethical, but the context does matter.

Maybe the real problem is in implementation, centralized middleboxes are the past and distributed software with centralized configuration management the future, and the best way to handle this kind of security problem is with centrally managed browser extensions that perform the same function as the malware scanning middle boxes. No matter what system you choose to do scanning you require a high level of administrative access on the end-point hosts, if you don't have that then you probably shouldn't be attempting this kind of inspection.

corporate IT administrators

Posted Mar 9, 2016 18:41 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Good luck deploying your distributed software on all the nodes that do https today. Starting with all the iot stuff.

Centralized middleboxes exist because any generalized deployment on a non-trivial network parc is harder than hell. gmail, facebook, all the current web giants, exploit the economies of scale of centralizing processing.

corporate IT administrators

Posted Mar 9, 2016 15:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

It's not disinformation, I was simply reporting the facts. Facts which you didn't address at all. Because they make your whole stance look as feeble as it actually is. You trust "corporate IT administrators" as proxies for difficult security problems. That's a terrible joke, as I illustrated.

I want to underscore that I wasn't giving a vague example of what might happen, I was describing reality, as it was when I wrote about it, on the ground, at a regulated financial company with a multi-billion dollar market capitalisation.

corporate IT administrators

Posted Mar 10, 2016 9:24 UTC (Thu) by paulj (subscriber, #341) [Link] (13 responses)

You're complaining that the browsers are somehow refusing to reasonably act in providing a MITM vector friendly to corporate proxies to monitor traffic of users' who are contractually (and lawfully) obliged to agree to such monitoring. The problem is there no known way to implement this that doesn't also give bad guys a MITM vector.

Please explain exactly how a browser, acting on behalf of a user, is supposed to distinguish between a MITM proxy that the user /should/ allow and one it should not?

It has to be technically possible and implementable, otherwise you're just howling at the moon.

corporate IT administrators

Posted Mar 10, 2016 13:37 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (12 responses)

How do you recognize anything on the Internet ? You show the user the proxy URL, you show the user the proxy cert, and you ask if he authorizes proxying by this entity.

And you give him a console to check what he authorized in the past so he can revoke at need.

No different from GPG, ssh, all the other secure systems on earth.

What you do *not* do is decide on behalf of the user. That's *his* data stream *his* decision, not yours.

corporate IT administrators

Posted Mar 10, 2016 19:39 UTC (Thu) by flussence (guest, #85566) [Link]

This far into the circus act I'm beginning to wonder whether you actually have no clue what a corporate network and IT infrastructure is, and why its requirements (legal and technical) require proxies. The other possibility is that you're being paid to misunderstand everything being explained to you, which makes your employer/sponsor look like a bit of an idiot.

corporate IT administrators

Posted Mar 10, 2016 20:59 UTC (Thu) by paulj (subscriber, #341) [Link] (10 responses)

And how will the net security effect of that approach be any different to the current "install a root cert and let the proxy MITM everything" approach of today?

corporate IT administrators

Posted Mar 10, 2016 21:25 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

A permissions dialog is going to pop up on every new connection? It sounds like the net security effect is mostly in making it unusable.

I'd hazard that approximately 100% of network owners wouldn't want this, and 99.9% of network users wouldn't want it either.

corporate IT administrators

Posted Mar 11, 2016 12:13 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (4 responses)

Sure, let's implement it the dumbest way possible, and then remove it because the implementation is dumb.

corporate IT administrators

Posted Mar 13, 2016 3:49 UTC (Sun) by bronson (subscriber, #4806) [Link] (3 responses)

Isn't that exactly what you proposed?

> You show the user the proxy URL, you show the user the proxy cert, and you ask if he authorizes proxying by this entity.

corporate IT administrators

Posted Mar 14, 2016 14:09 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (2 responses)

I never proposed "A permissions dialog is going to pop up on every new connection"

In fact I explicitly wrote about needing an UI to handle revocations, ie the browser remembering the permissions till the user revokes them.

corporate IT administrators

Posted Mar 14, 2016 19:24 UTC (Mon) by bronson (subscriber, #4806) [Link] (1 responses)

Curious then, how else are you going to show the proxy URL and cert, and wait for permission? (Gnome and KDE experience has shown that notifications aren't enough.)

corporate IT administrators

Posted Mar 16, 2016 15:29 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Sure you need to show the "do you trust xxxx to proxify your traffic" dialog. But once not every time you connect.

I won't say that's trivial, but that's not *that* hard. Browsers do such messages all the time when there is something they don't like (dns, cert, etc).

On an ideal properly integrated desktop that would go on the network connexion widget like wifi passwords and vpns (from a functional POW a proxy is a pure HTTP/s VPN)

corporate IT administrators

Posted Mar 11, 2016 12:10 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (2 responses)

Please, do not discuss security matters if you have no understanding of why making permissions explicit, auditable, and revocable, matters.

corporate IT administrators

Posted Mar 11, 2016 21:52 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

Good way to answer the question...

corporate IT administrators

Posted Mar 14, 2016 14:16 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

"Let's ignore all the content in a (long) thread, and restart from the beginning". Is that really a question?

corporate IT administrators

Posted Mar 22, 2016 17:58 UTC (Tue) by nye (guest, #51576) [Link]

>And how will the net security effect of that approach be any different to the current "install a root cert and let the proxy MITM everything" approach of today?

It would mean that all of the original TLS information is available to the browser, which can verify it and present it to the user in the usual way, rather than being stripped by the proxy and replaced with something else as is currently necessary because the only way to proxy https is nasty MITM shenanigans.

TLS certificate management on Android

Posted Mar 22, 2016 17:50 UTC (Tue) by nye (guest, #51576) [Link]

>It's more important to protect the majority of Internet users than to make life easier for corporate IT administrators trying to do things they shouldn't.

When the fuck did "provide a caching proxy for the use of clients configured to trust it, at home, at work, or otherwise" become "corporate IT administrators trying to do things they shouldn't"?

How did we reach this state where obvious brokenness is defended by invoking rampant mindless paranoia, and otherwise seemingly intelligent people swallowing the bullshit?

I guess caching proxies are used by terrorists, or paedophiles, or communists, or something? I bet Hitler would have used one if the technology had been available, so it must be the worst form of devilry, right?

Congratulations, you've rendered me insensible with rage.

TLS certificate management on Android

Posted Mar 3, 2016 12:42 UTC (Thu) by robbe (guest, #16131) [Link]

Did you (or anyone else reading this) get nameConstraints working across a solid majority of browsers? I couldn’t… and I’d really like to have our own internal CA constrained to internal names.

These intranet services are the main holdouts here that don’t have Letsencrypt certs on them. The other being stupid appliances where automation is neigh-impossible, and you’d have to click through a daft web-interface every three months to update the certificate.

TLS certificate management on Android

Posted Mar 3, 2016 15:52 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

So many TLS stacks fail to honor nameConstraints that allowing such a certificate today would be quite dangerous.

TLS certificate management on Android

Posted Mar 3, 2016 15:54 UTC (Thu) by josh (subscriber, #17465) [Link]

That said, while nameConstraints doesn't yet work in enough software to deploy this widely, I'd be interested in the ability to manually tell a browser or other software "allow this root CA, but *only* for subdomains of this domain, not all sites despite what the cert says". That would work nicely for Intranet sites that use a common CA root.