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.
(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.
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.
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.