Questions about signing an intermediate CA

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions about signing an intermediate CA

Michael Leone
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. But before I do that, I have a couple of questions.

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, and so I should just be able to 

openssl ca -in <file> -out <file>

and maybe the -extfile, to specify SANs.

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. And the rest of the examples seem to be how to sign using the resulting intermediate CA cert itself, which again, is not what I will be doing .

Any pointers appreciated. Thanks!


--

Mike. Leone, <mailto:[hidden email]>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

This space reserved for future witticisms ...
Reply | Threaded
Open this post in threaded view
|

RE: Questions about signing an intermediate CA

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] 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
Reply | Threaded
Open this post in threaded view
|

Re: Questions about signing an intermediate CA

Karl Denninger
In reply to this post by Michael Leone
On 2/12/2020 11:32, Michael Leone wrote:
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. But before I do that, I have a couple of questions.

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, and so I should just be able to 

openssl ca -in <file> -out <file>

and maybe the -extfile, to specify SANs.

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. And the rest of the examples seem to be how to sign using the resulting intermediate CA cert itself, which again, is not what I will be doing .

Any pointers appreciated. Thanks!

You have to sign the intermediate with the root in order to maintain the chain of custody and certification.

That is, the chain of trust is Root->Intermediate->......-> End Entity

You can (of course) branch more than once; it is common to have more than one Intermediate, for example, for different types of entity for which different parts of an organization have responsibility, and you can sub-delegate intermediates as well.

Just note that when an end entity certificate is validated the entire chain back to the root of trust (which is self-signed) has to be able to be verified.

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Questions about signing an intermediate CA

Michael Leone


On Wed, Feb 12, 2020 at 1:24 PM Karl Denninger <[hidden email]> wrote:
On 2/12/2020 11:32, Michael Leone wrote:
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. But before I do that, I have a couple of questions.

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, and so I should just be able to 

openssl ca -in <file> -out <file>

and maybe the -extfile, to specify SANs.

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. And the rest of the examples seem to be how to sign using the resulting intermediate CA cert itself, which again, is not what I will be doing .

Any pointers appreciated. Thanks!

You have to sign the intermediate with the root in order to maintain the chain of custody and certification.


Well, yes. Sorry if that wasn't clear. Yes, the only CA I have is the root, so that is what I will be signing with. So what  I am asking, is the signing command different for an intermediate CA than for a regular (I guess the term is "End Entity") certificate?

(I already have the CA cert pushed out into the certificate stores of all my domain members, so any new cert, issued by either the root or the intermediate, will chain fully. (once I push out the intermediate cert to all domain members).


Reply | Threaded
Open this post in threaded view
|

Re: Questions about signing an intermediate CA

Michael Leone
In reply to this post by Michael Wojcik
On Wed, Feb 12, 2020 at 1:16 PM Michael Wojcik <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

RE: Questions about signing an intermediate CA

Michael Wojcik
In reply to this post by Michael Leone
> From: openssl-users [mailto:[hidden email]] On Behalf Of Michael Leone
> Sent: Wednesday, February 12, 2020 11:59

> ... the only CA I have is the root, so that is what I will be signing with.

This is incorrect. A CA is not a certificate. A CA is an organization or individual who controls one or more root certificates, and possibly one or more intermediate certificates.

Both root and intermediate certificates are CA certificates, in the sense that they should have the CA:TRUE basic constraint.

> So what I am asking, is the signing command different for an intermediate
> CA than for a regular (I guess the term is "End Entity") certificate?

Intermediate *certificate*, not "CA".

The command per se isn't necessarily different. What's different is what extensions are present in the certificate, per my other note.

> I already have the CA cert pushed out into the certificate stores of all
> my domain members, so any new cert, issued by either the root or the
> intermediate, will chain fully. (once I push out the intermediate cert to
> all domain members).

Note that servers should (CA/BF rules, and maybe PKIX? I don't remember for certain) send not just their entity certificate but the whole chain excepting the root. Having clients install the intermediate isn't a bad idea, and certainly has its use cases (e.g. user certificates for S/MIME), but servers are supposed to assume clients may not have anything more than the root.

--
Michael Wojcik

Reply | Threaded
Open this post in threaded view
|

RE: Questions about signing an intermediate CA

Michael Wojcik
In reply to this post by Michael Leone
> From: Michael Leone [mailto:[hidden email]]
> Sent: Wednesday, February 12, 2020 12:10

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

Well, probably not verbatim, since I'm pretty sure I set at least that nsComment value. But, yes, it's not surprising if you already have a v3_intermediate_ca section.

> But I don't see how to use that section specifically, or when it's
> needed to use that section.

You use it by specifying the -extensions option on the ca subcommand:

$ openssl ca -in something.csr -out something.pem -extensions v3_intermediate_ca

And you need it when you're signing an intermediate certificate, because the Basic Constraints and EKU have to be set appropriately. (Well, often you can get by, for some use cases, with non-conforming intermediate certificates. But careful peers will be unhappy with entity certificates signed by a non-conforming intermediate.)

> ... an end entity (I guess that's the term - you know, a "regular"
> certificate, like something used by a web server to secure traffic).

Nomenclature varies, but for example PKIX (RFC 3647) refers to "CA-certificates" and "end entity certificates". They qualify "entity" with "end" because they use "entity" broadly to refer to anything that a certificate might identify, including a CA. I generally use just "entity" to refer to leaf certificates in the hierarchy, because "end entity" is cumbersome, and terms such as "root" and "intermediate" are more useful for certificates elsewhere in the hierarchy.

Of course, there are X.509-based networks which are not strictly hierarchical. Even with PKIX we see things like cross-signing, and you can construct any sort of graph, even cyclical, of certificate relationships. (There are some specifications for non-hierarchical certificate networks.) Describing certificates in those sorts of environments is more complicated. But those are still niche applications.

--
Michael Wojcik
Reply | Threaded
Open this post in threaded view
|

Re: Questions about signing an intermediate CA

Michael Leone
In reply to this post by Michael Wojcik


On Wed, Feb 12, 2020 at 2:22 PM Michael Wojcik <[hidden email]> wrote:
> From: openssl-users [mailto:[hidden email]] On Behalf Of Michael Leone
> Sent: Wednesday, February 12, 2020 11:59

> ... the only CA I have is the root, so that is what I will be signing with.

This is incorrect. A CA is not a certificate. A CA is an organization or individual who controls one or more root certificates, and possibly one or more intermediate certificates.

Even though I used what might be the wrong terms, I'm sure you knew what I meant ...
 
Reply | Threaded
Open this post in threaded view
|

Re: Questions about signing an intermediate CA

Karl Denninger
In reply to this post by Michael Leone
On 2/12/2020 12:59, Michael Leone wrote:


On Wed, Feb 12, 2020 at 1:24 PM Karl Denninger <[hidden email]> wrote:
On 2/12/2020 11:32, Michael Leone wrote:
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. But before I do that, I have a couple of questions.

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, and so I should just be able to 

openssl ca -in <file> -out <file>

and maybe the -extfile, to specify SANs.

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. And the rest of the examples seem to be how to sign using the resulting intermediate CA cert itself, which again, is not what I will be doing .

Any pointers appreciated. Thanks!

You have to sign the intermediate with the root in order to maintain the chain of custody and certification.


Well, yes. Sorry if that wasn't clear. Yes, the only CA I have is the root, so that is what I will be signing with. So what  I am asking, is the signing command different for an intermediate CA than for a regular (I guess the term is "End Entity") certificate?

No, other than specifying the signing certificate to be used (e.g. the root CA) -- the certificate ITSELF, however, is different than an end-entity certificate.  The EKU constraints should be correct (e.g. chain length, etc) and "CA:true" has to be set for it (and must NOT be set on an end-entity certificate.)  I have no clue what Microsoft does or doesn't do with their certificate management stuff; I use OpenSSL to do it.

--
Karl Denninger
[hidden email]
The Market Ticker
[S/MIME encrypted email preferred]

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Questions about signing an intermediate CA

Michael Wojcik
In reply to this post by Michael Leone
> From: Michael Leone [mailto:[hidden email]]
> Sent: Wednesday, February 12, 2020 12:35

> Even though I used what might be the wrong terms, I'm sure you knew what I meant ...

Sure. But PKIX, and X.509-based PKI more generally, are - not to mince words - horrible. They're agonizingly complicated and confusing, and arguably fundamentally broken in various respects. (See for example the issues raised by the infamous "The OSI of a New Generation" presentation.)

And here on the openssl-users list there are people with widely varying experience with and understanding of these matters; and the list is archived in various places, which means there's some chance someone will read these notes years from now. Many of those people don't have the time to become experts in PKI, and will want to be able to search for additional information based on what they see here.

So it's useful to try to be very precise in our terminology.

Often, for example, the cognoscenti will refer to a certificate's "purpose". That's an ambiguous term. In context it might refer to Basic Constraints, or Key Usage, or Extended Key Usage, or even the old Netscape Cert Type; it might refer to something inferred from other attributes (if Subject DN is the same as Issuer DN, then it's self-signed and possibly a root); or it might refer to something particular to its PKI or application, and not actually an attribute of the certificate at all. That's fine when we all understand what we're talking about. On the list, however, it's best to be explicit: "EKU should include TSL Web Server Authentication for this type of certificate" and so forth.

For some readers, using "CA" and "certificate" interchangeably could be very confusing.

So I'm not being pedantic just for its own sake (I can yell at the television for that). Apologies if it came across that way.

--
Michael Wojcik

Reply | Threaded
Open this post in threaded view
|

Re: Questions about signing an intermediate CA

Michael Leone
On Wed, Feb 12, 2020 at 4:19 PM Michael Wojcik
<[hidden email]> wrote:
>
> > From: Michael Leone [mailto:[hidden email]]
> > Sent: Wednesday, February 12, 2020 12:35
>
> > Even though I used what might be the wrong terms, I'm sure you knew what I meant ...
>
> Sure. But PKIX, and X.509-based PKI more generally, are - not to mince words - horrible. They're agonizingly complicated and confusing, and arguably fundamentally broken in various respects. (See for example the issues raised by the infamous "The OSI of a New Generation" presentation.)

I'm not sure how "infamous" it is, as I've never heard of it, even in
passing. :-)

> And here on the openssl-users list there are people with widely varying experience with and understanding of these matters; and the list is archived in various places, which means there's some chance someone will read these notes years from now. Many of those people don't have the time to become experts in PKI, and will want to be able to search for additional information based on what they see here.

Yeah, that would be me. :-)

> So it's useful to try to be very precise in our terminology.

You're right, of course.
>
> Often, for example, the cognoscenti will refer to a certificate's "purpose". That's an ambiguous term. In context it might refer to Basic Constraints, or Key Usage, or Extended Key Usage, or even the old Netscape Cert Type; it might refer to something inferred from other attributes (if Subject DN is the same as Issuer DN, then it's self-signed and possibly a root); or it might refer to something particular to its PKI or application, and not actually an attribute of the certificate at all. That's fine when we all understand what we're talking about. On the list, however, it's best to be explicit: "EKU should include TSL Web Server Authentication for this type of certificate" and so forth.
>
> For some readers, using "CA" and "certificate" interchangeably could be very confusing.
>
> So I'm not being pedantic just for its own sake (I can yell at the television for that). Apologies if it came across that way.

I get it. Sorry I snapped. No apologies needed on your side.

--

Mike. Leone, <mailto:[hidden email]>

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: <http://www.flickr.com/photos/mikeleonephotos>

This space reserved for future witticisms ...
Reply | Threaded
Open this post in threaded view
|

RE: Questions about signing an intermediate CA

Michael Wojcik
> From: Michael Leone [mailto:[hidden email]]
> Sent: Wednesday, February 12, 2020 16:09
>
> On Wed, Feb 12, 2020 at 4:19 PM Michael Wojcik
> <[hidden email]> wrote:
> >
> > the infamous "The OSI of a New Generation" presentation
>
> I'm not sure how "infamous" it is, as I've never heard of it, even in
> passing. :-)

Well, infamous in certain circles. I should have looked it up and cited it property. It's part 2a of Peter Gutmann's "godzilla crypto tutorial":

https://www.cs.auckland.ac.nz/~pgut001/tutorial/index.html

At a mere 973 slides, it's a breezy introduction to Cryptography as It is Used. Somewhat old now (I'm not sure when Gutmann first published it), but there's still a lot of good background there.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


Reply | Threaded
Open this post in threaded view
|

RE: Questions about signing an intermediate CA

Michel
In reply to this post by Michael Wojcik
And I am one of those who appreciates very much your explanations/clarifications for a long time.
Thank you again Michael.

> [...]
> And here on the openssl-users list there are people with widely varying experience with and understanding of these matters;
> [...]
> So it's useful to try to be very precise in our terminology.
> [...]
> --
> Michael Wojcik