== The "web" TLS world is different from the non-public one in practice A while back I wrote an entry about [[how TLS increasingly exists in three different worlds TLSThreeWorlds]]; the world of public HTTPS (*web TLS*), the world of *non-web public TLS* as used by protocols like IMAP, and the world of *internal TLS*. That entry mostly took the perspective of operating services, but there's another perspective where there is *web TLS* and *private TLS*. This is the perspective of TLS certificate issuance and TLS Certificate Authorities. This *web TLS* world of TLS certificate issuance is now mostly automated, with relatively few choices for you to make and so relatively few ways to shoot yourself in the foot (even if you try, your Certificate Authority will mostly refuse to accept it). This world has high visibility and legibility for what happens in it, not many tricks, and how browsers behave with the result is mostly well documented (and modern). This world has occasional glitches [[when unusual or surprising events https://www.agwa.name/blog/post/fixing_the_addtrust_root_expiration]] happen, and not everything behaves the way browsers do, but for the most part it's hard to screw up and relatively easy to diagnose. And even if you're going to use your TLS certificate for something other than HTTPS, your Certificate Authority is almost certainly following the rules of web TLS. The *private TLS* world is far more wild. When you make your own Certificate Authority and issue your own TLS certificates, there are many choices to make and thus many ways to get things wrong (either in obvious or in subtle ways). What servers and clients intended for private TLS usage will accept and how they behave is much less predictable and probably far more variable. Diagnosing problems is much more difficult, especially since programs and tools from the web TLS world may behave differently from programs in the private TLS world. There are more tricks you can potentially pull, but at the same time some of the tricks from the web TLS world may not work (despite tools from the web TLS world telling you they should). The private TLS world is the one in which [[I failed to arrange a graceful TLS root certificate rollover for our OpenVPN server ../sysadmin/FailingAtTLSRootRollover]]. It's a world where some things may care about [[which of TLS's two time representations you wind up using TLSTimeRepresentations]]. It's a world with much more operational uncertainty in practice, unless you're quite experienced and perhaps deeply familiar with the software you're using. (The world of non-web public TLS is in some ways in the middle, because client and server software may not behave as predictably as web browsers and web servers do. However, this is generally considered a bug, and public TLS certificates are all issued up to the standards of browsers.) I've come to think that you want to stay in the web TLS world as much as possible, even if it's initially less convenient and more work. The web TLS world constraints what everyone does, and when it comes to TLS, that can be a very good thing. Not just for security, but also because there are fewer things to test, fewer things to go wrong, and a much higher chance that you'll be following the happy path that everyone else also does.