Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 1:16 PM Michael Wojcik <
Michael.Wojcik at microfocus.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200212/28d5971e/attachment-0001.html>