On Wed, Feb 12, 2020 at 1:16 PM Michael Wojcik <Michael.Wojcik@xxxxxxxxxxxxxx> wrote:
Terminological note: "Windows intermediate CA" isn't really a meaningful phrase. There's nothing OS-specific about a CA. What you're creating is a Windows-hosted implementation of your intermediate-CA functions. And, actually, what you're really creating is a Windows-hosted implementation of your CA's intermediate functions. (It's one CA, with one or more root signing certificates and one or more intermediate signing certificates, associated private keys, and other infrastructure such as issued-certificates database and CRL.)
There's nothing preventing someone from taking a Windows-hosted CA and moving it to some other platform, or vice versa, assuming the infrastructure data can be converted appropriately.
Noted.
I suppose it depends on what you mean by "differently". Intermediate signing certificates are not the same as entity certificates, so you have to do *something* to tell the CA implementation what you're doing.
"Differently" means issuing the signing command differently than I would for any other requested cert. As in my example, I just do "sudo openssl ca -in <infile> -out <outfile>", and don't specify any other specific configurations. And that works fine for webservers, domain controllers, load balancers, etc. They request certain extensions, and that command gives those requested extensions..
Differences include:
- Intermediate certificates are signed by the root (unless you have multiple layers of intermediates; let's ignore that possibility). Entity certificates are signed by an intermediate.
I only have one root CA, so that's what I will be signing with.
- Intermediate certificates will (should) have CA:TRUE in Basic Constraints; entity certificates will have CA:FALSE.
I imagine that will already be in the request from the Windows CA, although I haven't created it yet, to verify that. The command to create the request specifically asks if it is to be an intermediate CA, so I can't imagine they would ask that unless it was to use a specific template for that type of request. (yes, it is possible to choose which template the request uses, and you could, at that point, add in anything you wanted it to ask for - basic constraints, etc).
Here's the config section I use for my test intermediate certificate:
[ v3_intermediate_ca ]
authorityKeyIdentifier = keyid:always,issuer
# pathlen:0 means these certs can only sign non-CA certs
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
nsComment = "TestCA Intermediate Certificate"
subjectKeyIdentifier = hash
Yes, the openssl.cnf I have came with that section, too. But I don't see how to use that section specifically, or when it's needed to use that section.
No, but you are generating and signing your intermediate CA certificate using OpenSSL, so that part of the process in the examples is likely relevant.
Now, that said: Microsoft likes to put some extensions of its own in certificate requests. It's been some years since I messed around with Microsoft's certificate services, so I don't remember details; but it's possible those extensions might be relevant to how the Windows implementation of the CA intermediate-signing functions works. So you might want to use openssl to see what extensions are in the CSR created by Windows, and whether they're in the certificate your CA issues.
I do know how to show the details of requests, and signed certificates, yes. And I will do that. I just wasn't sure of any differences in how to sign an intermediate CA, as opposed to an end entity (I guess that's the term - you know, a "regular" certificate, like something used by a web server to secure traffic).
Thanks
