> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Michael Leone > Sent: Wednesday, February 12, 2020 10:32
> So we are mostly a MS Windows shop. But I use a Linux openssl as my root CA. > What I am planning on doing, is creating a Windows intermediate CA, and using > that to sign all my internal requests. 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. > I have the steps to install the certificate services in AD, and create an > intermediate CA request. What I'm wondering is, do I sign that cert > differently > than any normal cert? I don't see why I would. I mean, the request should > specify that it wants to be a CA... 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. 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. - Intermediate certificates will (should) have CA:TRUE in Basic Constraints; entity certificates will have CA:FALSE. - Intermediate certificates will also generally have the critical and pathlen Basic Constraints. - Intermediate certificates need digitalSignature, cRLSign, and keyCertSign in their Extended Key Usage. Entity certificates will typically have EKUs with digitalSignature and keyEncipherment (servers) or possibly those plus nonRepudiation (users). So when signing an intermediate certificate you'll probably need to use a suitable extensions configuration section. You might be able to convince Windows to get all of those in the request, and copy_extensions=copy might copy all of them to the certificate, but I haven't tried that. My preference would be to enforce them at the CA end. 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 (Note that my CA root certificate has pathlen:1 in its basicConstraints.) Usual disclaimer: There are many people who know more about this stuff than I do, and I might well be violating some best practice or CA/BF rules (which you might or might not care about) or something. > Am I correct in thinking that? I see many, many openssl examples, but > they're all for creating an intermediate CA using openssl, which I'm not > doing. 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. -- Michael Wojcik
