RE: Questions about signing an intermediate CA

[Michel]

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

RE: Questions about signing an intermediate CA

[Michael Wojcik]

> From: Michael Leone [mailto:tur...@mike-leone.com]
> Sent: Wednesday, February 12, 2020 16:09
>
> On Wed, Feb 12, 2020 at 4:19 PM Michael Wojcik
>  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

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 4:19 PM Michael Wojcik
 wrote:
>
> > From: Michael Leone [mailto:tur...@mike-leone.com]
> > 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, 

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...

RE: Questions about signing an intermediate CA

[Michael Wojcik]

> From: Michael Leone [mailto:tur...@mike-leone.com]
> 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

Re: Questions about signing an intermediate CA

[Karl Denninger]

On 2/12/2020 12:59, Michael Leone wrote:
>
>
> On Wed, Feb 12, 2020 at 1:24 PM Karl Denninger  > 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  -out 
>>
>> 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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 2:22 PM Michael Wojcik <
michael.woj...@microfocus.com> wrote:

> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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 ...

RE: Questions about signing an intermediate CA

[Michael Wojcik]

> From: Michael Leone [mailto:tur...@mike-leone.com]
> 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

RE: Questions about signing an intermediate CA

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 1:16 PM Michael Wojcik <
michael.woj...@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  -out ", 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

Re: Questions about signing an intermediate CA

[Michael Leone]

On Wed, Feb 12, 2020 at 1:24 PM Karl Denninger  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  -out 
>
> 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).

Re: Questions about signing an intermediate CA

[Karl Denninger]

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  -out 
>
> 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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

RE: Questions about signing an intermediate CA

[Michael Wojcik]

> 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

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

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, 

PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Photo Gallery: 

This space reserved for future witticisms ...