Hacker News Reader

Comment by Someone1234 | Hacker News Reader

I'm glad (but unsurprised) to see they're doing things correctly (offline root, then using the intermediate CAs to generate actual certificates).

I tried to set up a similar (identical) scheme for use internally, but for some bonkers reason Microsoft's CA on 2008 R2 makes doing this almost "impossible." Or at least if it is possible it is insanely complex. It just really hated and rejected the concept of an offline root CA that didn't have a Microsoft CA running for it.

I'd love to be able to tell everyone doing an internal/corporate key-chain that "this is how it should be done" but holy heck does the tooling make it more complicated than it needs to be. I should just be able to install the public root key, hide the private root key indefinitely and it should "just work" for any key generated via the two intermediate CAs.

View on HN

Root-and-intermediate is a required practice by the CA/Browser forum. See section 6.1.7:

https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.p...

(I'm sort of curious how people still have trouble with cert chains, given how long this has been a requirement for all CAs.)

> (I'm sort of curious how people still have trouble with cert chains, given how long this has been a requirement for all CAs.)

There are several reasons for widespread confusion:

1. Different web server software have different ways to install intermediate certificates. Apache wants them to be in a separate file, nginx wants them concatenated with the main certificate.

2. The same certificate can take different chains of trust depending on the client. For example, recently issued PositiveSSL certificates come with two intermediate certificates, but most browsers already trust the second one. So a lot of people just install the first intermediate certificate and call it a day. This setup blows up as soon as you try to run some sort of API on your server (accessed with curl), because unlike browsers, the cacert package on most distros don't contain the second intermediate.

3. The certificates themselves are just a bunch of random letters delimited by a line of dashes. It's not clear at all in which order you should cat them together, and most GUI tools for viewing certificates don't clearly indicate the relationship between certificates, either.

Hopefully, the shell scripts provided by Let's Encrypt will prevent most of the obvious misconfigurations.

Another factor is that some browsers will automatically retrieve intermediate certificates that aren't supplied by the server. I'm not sure if it's still the case, but it used to be that Firefox would fail on HTTPS connections with a broken chain where IE would succeed.

http://serverfault.com/a/449144

You'll want to locate a copy of Brian Komar's book on Windows PKI; offline root is not hard, but many things in AD:CS land are more mysterious than they ought to be.

Personally I don't like AD:CS for an offline root, oddly bound-up in the OS guts as it is, and with an architecture-dependent cert db; just use openssl to gin up the root, and use AD:CS for issuance / online operations.

I just closed a project that did just this with a Microsoft CA. What issue did you have?

When you set up the intermediate CAs, I installed the root public key, but the intermediate CAs wanted to know "where" the CA running with the root private key was, I didn't have an online root (I generated then took it down), and the intermediate CA wasn't having any of that.

I did this a couple years ago and assisted another admin with an install last year. Here is one of the guides I used to get me through it:

https://itworldjd.wordpress.com/2013/03/20/ad-cs-2008-r2-ins...

If nothing else, you should be able to tell the intermediate CA to pretend that a root and then re-sign its public key with your actual root, and then hand the actual root to clients, and hand the new intermediate CA cert to servers to use in the chain. I'm pretty sure the signing process only depends on the public key, not on the entire cert.

This is how cross-signatures work: new CAs will get their intermediate keys cross-signed by existing CAs, so that you can construct a valid chain from them. This creates a different CA certificate, but it's using the same public key, so the end-entity certs validate with either CA certificate.

Reply on news.ycombinator.com