subject:"Intermediate CA"

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

> 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

2020-02-12 Thread Karl Denninger

On 2/12/2020 12:59, Michael Leone wrote:
>
>
> On Wed, Feb 12, 2020 at 1:24 PM Karl Denninger  <mailto:k...@denninger.net>> 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 <mailto: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

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

> 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

> 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

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

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

2020-02-12 Thread 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 <mailto: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

> 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

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, <mailto:tur...@mike-leone.com>

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

Re: [openssl-users] An example issuing an intermediate CA with policy mappings?

2018-09-26 Thread Dave Coombs

> On Sep 25, 2018, at 14:34, Krehbiel, Richard  wrote:
> 
> For my testing I want to explore the behaviors of policies, policy 
> constraints, and policy mappings.  I have figured out how to request and 
> issue certs with custom policy OIDs, but I haven't yet seen a method of 
> granting an intermediate cert with policy mappings.   Can openssl do this?  
> How?  Thanks.

Yes, I've used "openssl ca" to make certs with policy mappings in the past.  
Try something like this in your openssl.cnf, for use with "openssl ca 
-extensions test_ext" for example.  (I haven't tested with these exact values, 
but it should be a starting point.)

[openssl_init]
oid_section = new_oids
...

[new_oids]
issuerOID = Issuer Domain Policy, 1.2.3.4.5
subjectOID = Subject Domain Policy, 1.3.5.7.9
...

[test_ext]
policyMappings = @policy_mappings
...

[policy_mappings]
issuerOID = subjectOID

And if you want to map more than one subject domain policy OID to the same 
issuer domain policy OID, you can use issuerOID.0, issuerOID.1, issuerOID.2, 
etc, to differentiate them in the policy_mappings section.

Good luck,
  -Dave

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] An example issuing an intermediate CA with policy mappings?

2018-09-25 Thread Krehbiel, Richard

For my testing I want to explore the behaviors of policies, policy constraints, 
and policy mappings.  I have figured out how to request and issue certs with 
custom policy OIDs, but I haven't yet seen a method of granting an intermediate 
cert with policy mappings.   Can openssl do this?  How?  Thanks.


KASTLE SYSTEMS

855.527.8531  |  KASTLE.COM


Follow us on LinkedIn or 
Twitter for Security Tips!
Click 
Here
 to see why the Washington Post is calling our Hands-Free Mobile Credential 
"the end of the badge."

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to construct certificate chain when missing intermediate CA

2015-01-09 Thread Jakob Bohm


On 09/01/2015 03:45, Jerry OELoo wrote:

Hi All:
I am using X509_STORE_CTX_get1_chain() to get web site's full certificate chain.
Now I am encounter an issue that some web site does not return
intermediate CA certificate but only web site leaf certificate.

For example. https://globaltrade.usbank.com

Below is certificate I get.

Subject: /C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com
Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of
use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure
Server CA - G3

As my environment missing VeriSign Class 3 Secure Server CA - G3 certificate.

When open web site in Browsers (Chrome on windows), I can see
certificate chain is built successfully, I think this is because
browser should recognize VeriSign Class 3 Secure Server CA - G3 this
intermediate CA, and automatically installed crt into system.

So my question is how can I achieve same as browsers with openssl,
with openssl I can get error info. But where can I use program to
download VeriSign G3 certificate and installed automatically, then I
can build full certificate chain.

Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[20]
Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[27]
Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[21]



The trick is that many (not all) certificates now include an
AuthorityInformation Access (AIA) extension which
(optionally) gives a download URL for the next certificate
in the chain in case the browser does not have a local copy.
This is the same extension which also (in another optional
field) provides the URL of an OCSP revocation checking
server.

So in some clients (at least Internet Explorer 9+), the
procedure for each certificate is:

1. Using the full Issuer DN (which is a complex ASN.1
structure), put them in the same form (already done
because that part of the certificate has to be in the
strict DER format), then do a binary compare for
identity against the full Subject DN in all the
certificates received from the other end.

2. If this fails, do the same against all the
certificates in your local catalog of trusted root CAs.

3. If this fails, do the same against all the certificates
in your local catalog of known Intermediary CAs.

4. If this fails, do the same against all the certificates
in your local cache of previously downloaded certificates.

5. If this fails, look for an AIA extension in the cert
and check if that extension includes a certificate
download URL, then download from that URL to an in memory
variable.  If the validation ultimately succeeds, save
that downloaded certificate from memory to your local
cache.

OpenSSL 1.0.1 and older include functions to do steps 1
(if the other end sent the certificates in the order
needed) and 2.  That code may be coerced into doing steps
3 and 4 by putting the intermediary certificates into the
root store and checking if a certificate is self-signed
to decide if it is trusted or just a potentially
unverified intermediary.

OpenSSL 1.0.2 beta apparently includes better code for
most of these steps than 1.0.1.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

___
openssl-users mailing list
openssl-users@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to construct certificate chain when missing intermediate CA

2015-01-08 Thread Jerry OELoo

Hi All:
I am using X509_STORE_CTX_get1_chain() to get web site's full certificate chain.
Now I am encounter an issue that some web site does not return
intermediate CA certificate but only web site leaf certificate.

For example. https://globaltrade.usbank.com

Below is certificate I get.

Subject: /C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com
Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of
use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure
Server CA - G3

As my environment missing VeriSign Class 3 Secure Server CA - G3 certificate.

When open web site in Browsers (Chrome on windows), I can see
certificate chain is built successfully, I think this is because
browser should recognize VeriSign Class 3 Secure Server CA - G3 this
intermediate CA, and automatically installed crt into system.

So my question is how can I achieve same as browsers with openssl,
with openssl I can get error info. But where can I use program to
download VeriSign G3 certificate and installed automatically, then I
can build full certificate chain.

Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[20]
Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[27]
Peer cert subject[/C=US/ST=Minnesota/L=St. Paul/O=U.S.
Bank/OU=ISS/CN=globaltrade.usbank.com] depth[0] error[21]


-- 
Rejoice,I Desire!
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users

Re: How to create intermediate CA certificate with openssl

2014-11-27 Thread John Mok

Jerry,

When you create the intermediate certificate, you need to add the
following attribute :-

basicConstraints=CA:true

Otherwise, the intermediate CA certificate can not issue server certificates.

Best regards,  John Mok

On Thu, Nov 27, 2014 at 3:43 PM, Jerry OELoo oylje...@gmail.com wrote:
 Hi All:
 Now I want to create a certificate chain by myself.
 It will looks like as below:

 Server Certificate - Intermediate CA - Root CA.

 Now I am using openssl command to create these certificate files.


 # Create CA
 openssl genrsa -out ca.key 4096
 openssl req -new -x509 -nodes -sha1 -days 1825 -key ca.key -out ca.crt

 # Create Intermediate
 openssl genrsa -out intermediate.key 4096
 openssl req -new -sha1 -key intermediate.key -out intermediate.csr

 # CA signs Intermediate
 openssl x509 -req -days 1825 -in intermediate.csr -CA ca.crt -CAkey
 ca.key -set_serial 01 -out intermediate.crt

 # Create Server
 openssl genrsa -out test.example.com.key 4096
 openssl req -new -key test.example.com.key -out test.example.com.csr

 # Intermediate signs Server
 openssl x509 -req -days 1825 -in test.example.com.csr -CA
 intermediate.crt -CAkey intermediate.key -set_serial 01 -out
 test.example.com.crt


 Now I install ca.crt into WIndows7 local Trust Root Store. when I open
 test.example.com.crt file, I can see Certificate chain in
 Certification Path.

 But I get 1 warning information on intermediate certificate This
 certification authority is not allowed to issue certificates or cannot
 be used as an end-entity certificate.

 From search, I think this is because intermediate certificate/key is
 not a correct intermediate CA that it can not sign
 test.example.com.crt.

 Please kindly give me some suggestion about how to use openssl command
 to sign test.example.com.crt with intermediate CA. Thanks!

 --
 Rejoice,I Desire!
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

How to create intermediate CA certificate with openssl

2014-11-26 Thread Jerry OELoo

Hi All:
Now I want to create a certificate chain by myself.
It will looks like as below:

Server Certificate - Intermediate CA - Root CA.

Now I am using openssl command to create these certificate files.


# Create CA
openssl genrsa -out ca.key 4096
openssl req -new -x509 -nodes -sha1 -days 1825 -key ca.key -out ca.crt

# Create Intermediate
openssl genrsa -out intermediate.key 4096
openssl req -new -sha1 -key intermediate.key -out intermediate.csr

# CA signs Intermediate
openssl x509 -req -days 1825 -in intermediate.csr -CA ca.crt -CAkey
ca.key -set_serial 01 -out intermediate.crt

# Create Server
openssl genrsa -out test.example.com.key 4096
openssl req -new -key test.example.com.key -out test.example.com.csr

# Intermediate signs Server
openssl x509 -req -days 1825 -in test.example.com.csr -CA
intermediate.crt -CAkey intermediate.key -set_serial 01 -out
test.example.com.crt


Now I install ca.crt into WIndows7 local Trust Root Store. when I open
test.example.com.crt file, I can see Certificate chain in
Certification Path.

But I get 1 warning information on intermediate certificate This
certification authority is not allowed to issue certificates or cannot
be used as an end-entity certificate.

From search, I think this is because intermediate certificate/key is
not a correct intermediate CA that it can not sign
test.example.com.crt.

Please kindly give me some suggestion about how to use openssl command
to sign test.example.com.crt with intermediate CA. Thanks!

-- 
Rejoice,I Desire!
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SSL Root CA and Intermediate CA Certs.

2014-04-25 Thread Bruce Stephens

Edward Ned Harvey (openssl)
openssl-Z8efaSeK1ezqlBn2x/y...@public.gmane.org writes:

 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
 us...@openssl.org] On Behalf Of Michael Wojcik
 
 For someone who does want more background in cryptography, I'd
 recommend Schneier's /Applied Cryptography/ over /Cryptography
 Engineering/. The latter is for people implementing cryptography, which
 beginners should never do. 

 Huh - I thought Cryptography Engineering was the 3rd edition of
 Applied Cryptography, renamed.  But now I look at it, it seems you're
 right, it's a different book entirely.

Second edition of Practical Cryptography:
https://www.schneier.com/book-practical.html

 However, I never got the impression that Cryptography Engineering was
 meant for people implementing new algorithms or anything like that.

True, implementing isn't quite the right word. Using would be
closer, I suspect, though that doesn't necessarily carry the notion of
engineering (it's not a book about how to use PGP, or use some product
that incorporates TLS).

[...]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: SSL Root CA and Intermediate CA Certs.

2014-04-24 Thread Michael Wojcik

 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
 us...@openssl.org] On Behalf Of Edward Ned Harvey (openssl)
 Sent: Wednesday, 23 April, 2014 21:05
 Subject: RE: SSL Root CA and Intermediate CA Certs.

 I don't know how you learn about SSL/TLS, other than (a) reading the
 internet,

Man, I *tried* to read the Internet, but to be honest I got bogged down 
somewhere around 2.0.0.0.

 (b) taking some courses on general
 cryptography (there is a free online course at coursera.com, which is quite
 good.)  and (c) the thing that I actually found the most useful, a general
 book on cryptography called Cryptography Engineering

I'd argue that knowing about cryptography, and especially about implementing 
cryptography, is not very helpful for understanding SSL/TLS. Once you 
understand the purpose of the primitives - symmetric and asymmetric encryption, 
message digests, and digital signatures - the details don't help you with the 
SSL/TLS protocols themselves, or even with choosing cipher suites. (While some 
suites are vulnerable to particular attacks, you can take the word of crypto 
experts on those points and weigh them against your threat model. Understanding 
the specifics of the threat isn't necessary.) And understanding the details of 
cryptographic implementation won't help at all with PKI.

So I'd suggest starting with a quick cryptography primer that covers the 
primitives, and then something like Rescorla's /SSL and TLS/ book. It's not an 
exciting read, but then SSL/TLS is not an exciting subject.

For someone who does want more background in cryptography, I'd recommend 
Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter 
is for people implementing cryptography, which beginners should never do. As a 
rule of thumb, don't attempt to implement cryptography until you know when it's 
appropriate to violate this rule. And as Schneier himself has pointed out 
numerous times, cryptography isn't the problem, or the solution, anyway. (If 
you think cryptography is the solution to your problem, you don't understand 
cryptography and you don't understand your problem.)

 How and why do you trust any root certs?  Generally they're built-in to your
 OS or your browser, so you're just blindly trusting that those guys know what
 they're doing.

And they don't, and they don't care that they don't. The SSL/TLS 
X.509-with-well-known-CAs PKI is fundamentally broken and frequently 
compromised. But there's little we can do about it, so we pretend it isn't.

Of course the point of *any* security system is to raise the work factor for 
attackers until the cost of breaking the system is greater than the return for 
breaking it, under your threat model. SSL/TLS raises that cost over unencrypted 
communications. But it doesn't raise it nearly as much as it ought to, thanks 
to broken protocols, broken implementations, broken PKI, mismanagement, and 
user error.

-- 
Michael Wojcik
Technology Specialist, Micro Focus

This message has been scanned for malware by Websense. www.websense.com

RE: SSL Root CA and Intermediate CA Certs.

2014-04-24 Thread Edward Ned Harvey (openssl)

 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
 us...@openssl.org] On Behalf Of Michael Wojcik
 
 For someone who does want more background in cryptography, I'd
 recommend Schneier's /Applied Cryptography/ over /Cryptography
 Engineering/. The latter is for people implementing cryptography, which
 beginners should never do. 

Huh - I thought Cryptography Engineering was the 3rd edition of Applied 
Cryptography, renamed.  But now I look at it, it seems you're right, it's a 
different book entirely.  However, I never got the impression that Cryptography 
Engineering was meant for people implementing new algorithms or anything like 
that.  They very roundly and repeatedly beat into you, don't do that, without 
loads and loads of courses in mathematics, and a thoroughly vetted public and 
expert review process.  (Such as AES/SHA, etc).  They do a nice round job of 
covering the basics, describing what a block cipher is, what a hash algorithm 
is, PKI, symmetric/asymmetric, etc, what the characteristics are, how to think 
about threat models, and how to use these things in the ways that they're 
intended to be used, etc.  So don't discount Cryptography Engineering, but 
definitely consider Applied Cryptography in addition, or instead.

Re: SSL Root CA and Intermediate CA Certs.

2014-04-24 Thread Mark H. Wood

On Thu, Apr 24, 2014 at 12:57:36PM +, Michael Wojcik wrote:
[snip]
  How and why do you trust any root certs?  Generally they're built-in to your
  OS or your browser, so you're just blindly trusting that those guys know 
  what
  they're doing.
 
 And they don't, and they don't care that they don't. The SSL/TLS 
 X.509-with-well-known-CAs PKI is fundamentally broken and frequently 
 compromised. But there's little we can do about it, so we pretend it isn't.

Well, there certainly is something we can do about it, but you won't
like it any more than I do:

1.  Empty all of your trust stores.
2.  Add the cert.s of all CAs you already trust (if any) to your
trust stores.
3.  Investigate each CA you don't yet trust.  As you come to trust
one, add it to your trust stores.
4.  Pay attention to the CAs you trust, and evict any that seem to
have declined to a degree that worries you.
5.  Goto 3.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature

SSL Root CA and Intermediate CA Certs.

2014-04-23 Thread Kaushal Shriyan

Hi,

I am new to SSL/TLS Certificates. Please help me understand what is the
difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I
will appreciate if i can refer to some books or tutorials to know about
SSL/TLS technology.

Thanks and Regards,

Kaushal

Re: SSL Root CA and Intermediate CA Certs.

2014-04-23 Thread Graham Leggett

On 23 Apr 2014, at 2:23 PM, Kaushal Shriyan kaushalshri...@gmail.com wrote:

 I am new to SSL/TLS Certificates. Please help me understand what is the 
 difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I 
 will appreciate if i can refer to some books or tutorials to know about 
 SSL/TLS technology.

The closest thing you'll probably encounter in the real world to a digital 
certificate is a diploma or degree from an educational institution.

Anyone can write John Smith (PhD) on a piece of paper, that doesn't indicate 
anything special or prove anything. We might improve that by writing John 
Smith (PhD), Faculty of Philosophy on that piece of paper, but again, which 
faculty of philosophy? Never heard of them. Still, the piece of paper is 
useless. We can however write John Smith (PhD), Faculty of Philosophy, 
University of Cambridge on the piece of paper and sign the paper by putting a 
great big seal on the paper to make the paper hard to forge. In theory, we have 
heard of and trust the University of Cambridge, and in turn the University of 
Cambridge trusts the Faculty of Philosophy, which in turn trusts John Smith. If 
we trust the University of Cambridge, then we trust John Smith.

If we were using digital certificates instead of a certificate you might hang 
on a wall we might create a certificate called cn=John Smith (PhD) and get 
John Smith to sign it. This cert is largely meaningless, given that in order to 
trust John Smith we need to already trust John Smith using some out-of-band 
method. This is a self signed certificate.

If we were using certificates with a full certificate authority, we would 
instead have a certificate called cn=John Smith (PhD) issued by and signed by 
ou=Faculty of Philosophy which is in turn issued by and signed by 
o=University of Cambridge. The o=University of Cambridge certificate is 
called the ROOT CA certificate, because we have manually trusted that one using 
an out of band method (we might have got it built into our browser). The 
intermediate certificate is the ou=Faculty of Philosophy certificate, which 
is trusted by o=University of Cambridge and trusts cn=John Smith (PhD). John 
Smith is the leaf certificate trusted by the others.

All you need to do is trust the root CA certificate o=University of 
Cambridge, and you automatically trust everyone they trust, including cn=John 
Smith (PhD). Instead of relying on a big elaborate piece of paper with a wax 
seal on it, you rely on a mathematical equation that verifies that the 
certificate is legitimate, but the idea is the same.

Regards,
Graham
--

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: SSL Root CA and Intermediate CA Certs.

2014-04-23 Thread A . L . M . Buxey

Hi,

  I am new to SSL/TLS Certificates. Please help me understand what is the 
  difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I 
  will appreciate if i can refer to some books or tutorials to know about 
  SSL/TLS technology.
 
 The closest thing you'll probably encounter in the real world to a digital 
 certificate is a diploma or degree from an educational institution.

and to take this anaology to the final step University of Cambridge is the 
Root - you know and trust. other Universities and Technical colleges are 
roots too - you know and trust 
them (your certificate store/keychain will be full of trusted Roots) - however, 
other
orgs can hand out degrees too...these are affiliated to the main (root) CAs and 
have a lot
of rules/checks/balances so,

john smith, Degree from College of Town, underwritten by University of Foo

you trust Fooso you then trust College of Town which means you trust the
degree John holds.  College of Town is, in this case, an intermediate 
Certificate.

alan
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: SSL Root CA and Intermediate CA Certs.

2014-04-23 Thread Edward Ned Harvey (openssl)

From: owner-openssl-us...@openssl.org [mailto:owner-openssl-
us...@openssl.org] On Behalf Of Kaushal Shriyan

I am new to SSL/TLS Certificates. Please help me understand what is the
difference between ROOT CA Certs and Intermediate Certs or Chain Certs. I
will appreciate if i can refer to some books or tutorials to know about
SSL/TLS
technology.

I don't know how you learn about SSL/TLS, other than (a) reading the internet,
and working on it a lot, (b) taking some courses on general cryptography (there
is a free online course at coursera.com, which is quite good.) and (c) the
thing that I actually found the most useful, a general book on cryptography
called Cryptography Engineering, by Bruce Schneier, Niels Ferguson, Tadayashi
Kohno.

The root cert is self signed (so it is signed by itself.) The intermediate
cert is signed by the root cert. And your leaf cert is signed by the
intermediate.

A client who receives the cert chain (the root, intermediate, and leaf) can
follow a process to (1) verify that the leaf cert is not corrupted, and that
the intermediate cert has verified it. (b) verify that the intermediate cert
is not corrupted, and that the root cert has verified it, and that the
intermediate cert is in fact authorized by the root cert to perform the
authorization of the leaf cert. and (c) verify that the root cert is among the
list of certs that the client trusts.

How and why do you trust any root certs? Generally they're built-in to your OS
or your browser, so you're just blindly trusting that those guys know what
they're doing.
:��IϮ��r�m
(Z+�K�+1���x��h[�z�(Z+���f�y���f���h��)z{,���

Re: Trust only certs signed by intermediate CA

2013-03-09 Thread Kyle Hamilton

Create a new self-signed client CA certificate with the same key and
Subject, setting the Issuer to the Subject of the client CA, and signed
with the client CA private key.  Use this as your client-authenticatior
root.

Alternatively, you might play around with policies, but that relies on your
hierarchy already having policies in its certificates.

-Kyle H
On Mar 8, 2013 3:18 PM, Ian Pilcher arequip...@gmail.com wrote:

 +-+
 | Root CA |
 +-+
 /\
/  \
   /\
  /  \
 /\
/  \
   /\
  /  \
   +---++---+
   | Server CA || Client CA |
   +---++---+

 Given the above CA hierarchy, how can I configure a (server) SSL_CTX to
 accept connections *only* from clients which present a certificate
 signed by the Client CA?

 As is well documented, I cannot simply trust the Client CA.
 SSL_accept() will fail, because it cannot form a certificate chain all
 the way to the self-signed Root CA.

 I have found, however, that adding the Root CA certificate to the
 trusted certificate file/directory causes certificates signed by the
 Server CA to be accepted as well.  (The client has to present both its
 certificate and the Server CA certificate, but it is able to connect.)

 So how can I do this?  Thanks!

 --
 
 Ian Pilcher arequip...@gmail.com
 Sometimes there's nothing left to do but crash and burn...or die trying.
 

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Trust only certs signed by intermediate CA

2013-03-09 Thread Ian Pilcher

On 03/09/2013 10:40 AM, Kyle Hamilton wrote:
 Create a new self-signed client CA certificate with the same key and
 Subject, setting the Issuer to the Subject of the client CA, and signed
 with the client CA private key.  Use this as your client-authenticatior
 root.

Well yes.  I know I could workaround this by creating a self-signed root
for the clients.  The point of the question is how to do this with a
hierarchy like the one I've described.

It's becoming pretty clear that OpenSSL doesn't provide a simple way to
do this today.  (X509_V_FLAG_PARTIAL_CHAIN will probably enable this,
but it will be years before that makes its way into slower moving
distributions.)

 Alternatively, you might play around with policies, but that relies on
 your hierarchy already having policies in its certificates.

My current thinking is that I should be able to do it with a validation
callback.  I haven't worked out the details yet.

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Trust only certs signed by intermediate CA

2013-03-09 Thread Viktor Dukhovni

On Sat, Mar 09, 2013 at 11:04:06AM -0600, Ian Pilcher wrote:

 It's becoming pretty clear that OpenSSL doesn't provide a simple way to
 do this today.  (X509_V_FLAG_PARTIAL_CHAIN will probably enable this,
 but it will be years before that makes its way into slower moving
 distributions.)
 
  Alternatively, you might play around with policies, but that relies on
  your hierarchy already having policies in its certificates.
 
 My current thinking is that I should be able to do it with a validation
 callback.  I haven't worked out the details yet.

Yes, SSL_CTX_set_verify() or SSL_set_verify() allow you to validate
the trust chain yourself.

Note: Contrary to documentation the callback order is not necessarily
from the root down to the leaf in a single pass, rather this is only
the final list of callbacks. Prior callbacks may report other issues
in some other order (only error reports, never with ok=1).

Thus you may need to keep some state which you evaluate each time
the callback is made at depth 0. By final depth 0 call you'll
have all the required information and will be able to allow
or reject the connection (or just update its verification status
without failing the handshake).

This is the approach taken in the Postfix DANE implementation
(under development).

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Trust only certs signed by intermediate CA

2013-03-08 Thread Ian Pilcher

+-+
| Root CA |
+-+
/\
   /  \
  /\
 /  \
/\
   /  \
  /\
 /  \
  +---++---+
  | Server CA || Client CA |
  +---++---+

Given the above CA hierarchy, how can I configure a (server) SSL_CTX to
accept connections *only* from clients which present a certificate
signed by the Client CA?

As is well documented, I cannot simply trust the Client CA.
SSL_accept() will fail, because it cannot form a certificate chain all
the way to the self-signed Root CA.

I have found, however, that adding the Root CA certificate to the
trusted certificate file/directory causes certificates signed by the
Server CA to be accepted as well.  (The client has to present both its
certificate and the Server CA certificate, but it is able to connect.)

So how can I do this?  Thanks!

-- 

Ian Pilcher arequip...@gmail.com
Sometimes there's nothing left to do but crash and burn...or die trying.


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: X509 V1 intermediate CA vs end-entity

2012-10-21 Thread Kyle Hamilton

You can find out if the V1 cert verifies directly with any of the
certificates in the trust store or its own public key.  There's pretty
much nothing else you can do with it, other than try to link it to a
Distinguished Name that may or may not be useful.

Also, (EXFLAG_V1|EXFLAG_SS) doesn't tell you if it's intended to be a
CA certificate.  X.509 actually disclaims the idea of self-signed
certificates altogether (except as containers for trust anchors).

-Kyle H

On Tue, Sep 25, 2012 at 10:33 PM, sanjaya joshi joshi.sanj...@gmail.com wrote:
 Hi steve,
   Thanks. Got it.
 That means we can't differentiate between CA and end-entity in case of V1
 certificate.
 We can only find out if the V1 cert is a self-signed certificate or not.
 Correct ?

 Regards,
 Sanjaya


 On Wed, Sep 26, 2012 at 2:36 AM, Dr. Stephen Henson st...@openssl.org
 wrote:

 On Tue, Sep 25, 2012, sanjaya joshi wrote:

 
  We can conclude an X509 V1 certificate to be a root ca using
  (EXFLAG_V1|EXFLAG_SS).
  Similarly, is there a way to know whether an X509 V1 certificate is an
  intermediate CA or end-entity certificate ?
 

 You can't: there is nothing in a V1 certificate to mark it as a CA. You
 can't
 actually be sure it is a root CA using the test you mentioned above: it
 could
 be a self signed end entity certificate.

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: X509 V1 intermediate CA vs end-entity

2012-09-25 Thread Kyle Hamilton

Can you figure out a way to do it from the v1 fields?  keyUsage is an
extension requiring v3.

-Kyle H
On Sep 24, 2012 11:28 PM, sanjaya joshi joshi.sanj...@gmail.com wrote:

 Hi,

 We can conclude an X509 V1 certificate to be a root ca using
 (EXFLAG_V1|EXFLAG_SS).
 Similarly, is there a way to know whether an X509 V1 certificate is an
 intermediate CA or end-entity certificate ?

 Regards,
 Sanjaya

Re: X509 V1 intermediate CA vs end-entity

2012-09-25 Thread Dr. Stephen Henson

On Tue, Sep 25, 2012, sanjaya joshi wrote:

 
 We can conclude an X509 V1 certificate to be a root ca using
 (EXFLAG_V1|EXFLAG_SS).
 Similarly, is there a way to know whether an X509 V1 certificate is an
 intermediate CA or end-entity certificate ?
 

You can't: there is nothing in a V1 certificate to mark it as a CA. You can't
actually be sure it is a root CA using the test you mentioned above: it could
be a self signed end entity certificate.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: X509 V1 intermediate CA vs end-entity

2012-09-25 Thread sanjaya joshi

Hi steve,
  Thanks. Got it.
That means we can't differentiate between CA and end-entity in case of V1
certificate.
We can only find out if the V1 cert is a self-signed certificate or not.
Correct ?

Regards,
Sanjaya

On Wed, Sep 26, 2012 at 2:36 AM, Dr. Stephen Henson st...@openssl.orgwrote:

 On Tue, Sep 25, 2012, sanjaya joshi wrote:

 
  We can conclude an X509 V1 certificate to be a root ca using
  (EXFLAG_V1|EXFLAG_SS).
  Similarly, is there a way to know whether an X509 V1 certificate is an
  intermediate CA or end-entity certificate ?
 

 You can't: there is nothing in a V1 certificate to mark it as a CA. You
 can't
 actually be sure it is a root CA using the test you mentioned above: it
 could
 be a self signed end entity certificate.

 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

How to get intermediate CA certificate?

2011-05-11 Thread Akash Deo

Hi,

I want to validate a CA signed certificate against its CRL.

I have root certificate from CA. I have downloaded CRL for entity
certificate (using URI in CRL Distribution Points field).

Intermediate CA certificate is also required to verify entity certificate
against CRL.

Is there any way I can get the intermidiate CA certificate during SSL
handshake. Or what should be the way to get the intermidiate CA certificate?

Thanks  Regards,
Akash

Re: Intermediate CA

2011-01-13 Thread David Schwartz


On 1/12/2011 3:19 PM, Jijo wrote:

Hi All,

I hope this a basic question for you guys..

I'm trying to setup TLS connection between Client and Server.

In the server i did following things,
1. Created a selfsigned rootCA
2. Created IntermediateCA and signed with rootCA.
3. Create a Server Certificate and signed with intermediateCA.
4. Appened the rootCA also to the server Certficate.


In the Client.
1. Create a Server Certificate and signed with rootCA.
2. Stored CA as rootCA

Now i made a TLS connection from Client to Server and the client returns
an error:20 Unable to get Local Issuer Certficate.


If the client doesn't have the intermediate certificate, how can it know 
the server's certificate is valid?



I don't see this error if i use intermediateCA as CA in Client 

Am i supposed to use intermediateCA as CA in Client?


You have to get the IC to the client somehow. The usual method is to 
have the server send it. Does the server software provide a way to 
supply a certificate chain?


DS

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Intermediate CA

2011-01-13 Thread Jijo

Thanks for the response..

You have to get the IC to the client somehow. The usual method is to have
the server send it. Does the server software provide a way to supply a
certificate chain?

What do you mean by server sending it?  is it on TLS negotiation?

What do you mean by certificate chain? is it rootCA and IntermediateCA
combined in a pem file?.

Thanks
Jijo
On Thu, Jan 13, 2011 at 9:39 AM, David Schwartz dav...@webmaster.comwrote:

 On 1/12/2011 3:19 PM, Jijo wrote:

 Hi All,

 I hope this a basic question for you guys..

 I'm trying to setup TLS connection between Client and Server.

 In the server i did following things,
 1. Created a selfsigned rootCA
 2. Created IntermediateCA and signed with rootCA.
 3. Create a Server Certificate and signed with intermediateCA.
 4. Appened the rootCA also to the server Certficate.


 In the Client.
 1. Create a Server Certificate and signed with rootCA.
 2. Stored CA as rootCA

 Now i made a TLS connection from Client to Server and the client returns
 an error:20 Unable to get Local Issuer Certficate.


 If the client doesn't have the intermediate certificate, how can it know
 the server's certificate is valid?


  I don't see this error if i use intermediateCA as CA in Client 

 Am i supposed to use intermediateCA as CA in Client?


 You have to get the IC to the client somehow. The usual method is to have
 the server send it. Does the server software provide a way to supply a
 certificate chain?

 DS

 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

Re: Intermediate CA

2011-01-13 Thread michel


Hi Jijo,

I believe interesting information can be found here :
http://www.openssl.org/docs/ssl/SSL_CTX_use_certificate.html

Regards

Le 13/01/2011 17:16, Jijo a écrit :

Thanks for the response..

You have to get the IC to the client somehow. The usual method is to 
have the server send it. Does the server software provide a way to 
supply a certificate chain?


What do you mean by server sending it?  is it on TLS negotiation?

What do you mean by certificate chain? is it rootCA and IntermediateCA 
combined in a pem file?.


Thanks
Jijo



__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Intermediate CA

2011-01-12 Thread Jijo

Hi All,

I hope this a basic question for you guys..

I'm trying to setup TLS connection between Client and Server.

In the server i did following things,
1. Created a selfsigned rootCA
2. Created IntermediateCA and signed with rootCA.
3. Create a Server Certificate and signed with intermediateCA.
4. Appened the rootCA also to the server Certficate.


In the Client.
1. Create a Server Certificate and signed with rootCA.
2. Stored CA as rootCA

Now i made a TLS connection from Client to Server and the client returns an
error:20 Unable to get Local Issuer Certficate.

I don't see this error if i use intermediateCA as CA in Client 

Am i supposed to use intermediateCA as CA in Client?


Please let me know how it shall be used..

Thanks in advance..

Jijo

Re: Regarding intermediate CA

2010-10-17 Thread So Gerald

inside the file openssl.cnf let CA:TRUE


2010/10/15 Neeraj Jain nj...@cmctech.in

  Hello,



 We want to implement Root CA à  intermediate CA à Server certs, but we are
 not able to create intermediate CA, it would be great if you can help me.



 Thanks,

 Neeraj Jain

Re: Regarding intermediate CA

2010-10-17 Thread Patrick Patterson

Hi there:

On 2010-10-15, at 7:23 AM, Neeraj Jain wrote:

 Hello,
  
 We want to implement Root CA à  intermediate CA à Server certs, but we are 
 not able to create intermediate CA, it would be great if you can help me.

Setting up the openssl.cnf to make this work 100% right can be a bit tricky, 
however, the how-to that we have posted at:

http://www.carillon.ca/library/openssl_testca_howto_1.3.pdf

should help you through it.

Have fun!

---
Patrick Patterson
Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca





__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Regarding intermediate CA

2010-10-16 Thread Neeraj Jain

Hello,

 

We want to implement Root CA à  intermediate CA à Server certs, but we are
not able to create intermediate CA, it would be great if you can help me.

 

Thanks,

Neeraj Jain

Re: Can't recognize intermediate CA

2009-03-13 Thread Kyle Hamilton

The NSS developers (NSS being the library that Firefox uses) have
discussed the concept of OpenSSL's overspecified Authority Key
Identifier numerous times.  Most recently,
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/2ac539b4447c58cd?pli=1
has the main NSS developer's (Nelson Bolyard) thoughts on the matter.

-Kyle H

On Thu, Mar 12, 2009 at 5:39 PM, Rene Hollan rene.hol...@watchguard.com wrote:
  Yup. That fixed it.. At least as far as openssl verify -CAfile
 cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

 Oddly, firefox still rejects the end cert, even though both cacert.pem
 and intcert2.pem are in it's trust store. Is it possible that browsers
 actually ignore intermediate CA certs in their trust store and expect
 servers to provide them? That's the next thing for me to try (if only I
 can remember how to do that with openssl... :-)).


 -Original Message-
 From: owner-openssl-us...@openssl.org
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
 Sent: Thursday, March 12, 2009 4:23 PM
 To: openssl-users@openssl.org
 Subject: Re: Can't recognize intermediate CA


 If it's any consolation you aren't alone with that, it gets commented on
 quite often so much so in fact that it has an FAQ entry:

 http://www.openssl.org/support/faq.html#USER15

 You can just leave out the issuer+serial number combination from AKID
 too.

 Steve.
 --
 Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
 project core developer and freelance consultant.
 Homepage: http://www.drh-consultancy.demon.co.uk
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Can't recognize intermediate CA

2009-03-13 Thread Kyle Hamilton

Actually, in addition to the last link I gave,
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/31fe9768dcb00b2c/7fab610c48b40a9c?#7fab610c48b40a9c
has a link to the entire thread (which includes a couple more
questions and answers).

http://is.gd/n9o4 is a short redirect to that URL.

-Kyle H

On Thu, Mar 12, 2009 at 7:31 PM, Rene Hollan rene.hol...@watchguard.com wrote:
 Great, just great.

 My changes worked for IE, but not for Firefox.

 Apparently, Firefox does more stringent checking that IE, and indeed,
 than OpenSSL s_client ... (which gives a nice cert chain).


 -Original Message-
 From: Rene Hollan
 Sent: Thursday, March 12, 2009 6:34 PM
 To: 'openssl-users@openssl.org'
 Subject: RE: Can't recognize intermediate CA

  Sigh.

 Well, I added the intermediate CA to the cert chain sent by my proxy
 (and verified this with wireshark).

 OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443
 works and shows the trust chain.

 But, Firefox, with cacert.pem loaded into it's trust store still
 complains. :-(



 -Original Message-
 From: Rene Hollan
 Sent: Thursday, March 12, 2009 5:39 PM
 To: 'openssl-users@openssl.org'
 Subject: RE: Can't recognize intermediate CA

  Yup. That fixed it.. At least as far as openssl verify -CAfile
 cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

 Oddly, firefox still rejects the end cert, even though both cacert.pem
 and intcert2.pem are in it's trust store. Is it possible that browsers
 actually ignore intermediate CA certs in their trust store and expect
 servers to provide them? That's the next thing for me to try (if only I
 can remember how to do that with openssl... :-)).


 -Original Message-
 From: owner-openssl-us...@openssl.org
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
 Sent: Thursday, March 12, 2009 4:23 PM
 To: openssl-users@openssl.org
 Subject: Re: Can't recognize intermediate CA


 If it's any consolation you aren't alone with that, it gets commented on
 quite often so much so in fact that it has an FAQ entry:

 http://www.openssl.org/support/faq.html#USER15

 You can just leave out the issuer+serial number combination from AKID
 too.

 Steve.
 --
 Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
 project core developer and freelance consultant.
 Homepage: http://www.drh-consultancy.demon.co.uk
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org
 __
 OpenSSL Project                                 http://www.openssl.org
 User Support Mailing List                    openssl-us...@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Can't recognize intermediate CA

2009-03-13 Thread Dr. Stephen Henson

On Thu, Mar 12, 2009, Rene Hollan wrote:

  Yup. That fixed it.. At least as far as openssl verify -CAfile
 cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.
 
 Oddly, firefox still rejects the end cert, even though both cacert.pem
 and intcert2.pem are in it's trust store. Is it possible that browsers
 actually ignore intermediate CA certs in their trust store and expect
 servers to provide them? That's the next thing for me to try (if only I
 can remember how to do that with openssl... :-)).
 

Well if you had to add intermediate CAs to browser trust stores they would be
of limimted use. The whole idea is that you only need to add the root CA and
the browser will automatically trust intermediate CAs it hasn't seen before.

The SSL/TLS standards also require sending of the certificate chain (but the
root can be excluded).

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Can't recognize intermediate CA

2009-03-13 Thread Dr. Stephen Henson

On Thu, Mar 12, 2009, Rene Hollan wrote:

 True, but (a) it doesn't hurt to have both, and (b) if  the issuer
 doesn't have a SKID, AKID issuer/serial takes the place of an AKID
 keyid.
 

The disadvantage is that if you want to support more than one intermediate CA
(cross certification for example) and you have issuer+serial in AKID then
you'll get a mismatch with any new CA.

This has caused issues when some people had an intermediate CA expire before
the EE cert.

Technically AKID/SKID should just be a hint as to the correct issuer
certificate which can be ignored but some software (including OpenSSL
currently) requires a match.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA

2009-03-13 Thread Rene Hollan


Yeah, I realized that. I changed things to include an AKID if the issuer has a 
SKID, and the issuer's issuer's subject DN and issuer's serial number if not.

Got it all working finally, once I had the proxy chain it's intermediate CA. 
(When it wasn't doing this, I thought to try to add it to the trusted store of 
the browser, realizing that defeated the purpose of an intermediate CA, but 
wanted to test. That didn't work, but likely because I forgot the tell the 
browser what the trust chain rooted at the root CA was FOR.)


-Original Message-
From: owner-openssl-us...@openssl.org on behalf of Dr. Stephen Henson
Sent: Fri 3/13/2009 5:14 AM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA
 
On Thu, Mar 12, 2009, Rene Hollan wrote:

 True, but (a) it doesn't hurt to have both, and (b) if  the issuer
 doesn't have a SKID, AKID issuer/serial takes the place of an AKID
 keyid.
 

The disadvantage is that if you want to support more than one intermediate CA
(cross certification for example) and you have issuer+serial in AKID then
you'll get a mismatch with any new CA.

This has caused issues when some people had an intermediate CA expire before
the EE cert.

Technically AKID/SKID should just be a hint as to the correct issuer
certificate which can be ignored but some software (including OpenSSL
currently) requires a match.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

winmail.dat

RE: Can't recognize intermediate CA

Corrected yahoo.pem:

-BEGIN CERTIFICATE- 
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj 
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg 
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDANBgkqhkiG9w0BAQUF 
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD 
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR
sQ2OcZejF/Kjh7SHmM/NHIfSuraWJcayb4njNt8vKRYazfiFF8G2O7cOOe674KM9 
TpMPay5Ei0HMRb1uQjRaFmxVd1RoKw== 
-END CERTIFICATE- 

-Original Message-
From: Rene Hollan 
Sent: Thursday, March 12, 2009 3:01 PM
To: 'openssl-users@openssl.org'
Subject: Can't recognize intermediate CA

I'm tearing my hair out trying to get an intermediate CA to be
recognized.

I have cacert.pem signing intcert.pem signing (well, resigning),
yahoo.pem

Openssl verify verifiies intcert.pem against cacert.pem, but won't
verify yahoo.pem against intcert.pem.

Subject/issuer match. AKID dirname and issuer subject match, AKID serial
number and issuer serial number match. AKID and issuer SKID match. Basic
Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
measure) cert. Key usage CertSign and CRLSign on both root and
intermediate cert.

Can anyone see what is wrong? I'm including PEM versions of these certs.

Cacert.pem:

-BEGIN CERTIFICATE-
MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
AvScpmyMe2Mb
-END CERTIFICATE-


Intcert.pem:

-BEGIN CERTIFICATE-
MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m

FW: Can't recognize intermediate CA



 Arg can't even get end cert to paste in email window. Trying once more:

-BEGIN CERTIFICATE-
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDANBgkqhkiG9w0BAQUF
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR
sQ2OcZejF/Kjh7SHmM/NHIfSuraWJcayb4njNt8vKRYazfiFF8G2O7cOOe674KM9
TpMPay5Ei0HMRb1uQjRaFmxVd1RoKw== -END CERTIFICATE-

-Original Message-
From: Rene Hollan
Sent: Thursday, March 12, 2009 3:21 PM
To: Rene Hollan; 'openssl-users@openssl.org'
Subject: RE: Can't recognize intermediate CA

Corrected yahoo.pem:

-BEGIN CERTIFICATE- 
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMU
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+mVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+MDkwNloXDTExMDEwNDE3MDkwNloweDELM
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+AkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhI
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+ENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+SW5jLjEOMAwGA1UECxMFWWFob28xGDAWB
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+gNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCg
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+YEA484iMII/1qq0eEs8UQ1B4HHWD9Qj
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
1OHrG+NI66pQE4A3+2uTpVuX+DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAM
1OHrG+NI66pQE4A3+2uTpVuX+CBPAwHQYDVR0lBBYw
1OHrG+NI66pQE4A3+2uTpVuX+FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W
1OHrG+NI66pQE4A3+2uTpVuX+7qyiacBd5dbiLIySj
1OHrG+NI66pQE4A3+2uTpVuX+9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0
1OHrG+NI66pQE4A3+2uTpVuX+bR6FQpE4wTDEgMB4G
1OHrG+NI66pQE4A3+2uTpVuX+A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgN
1OHrG+NI66pQE4A3+2uTpVuX+VBAsTCEZpcmV3YXJl
1OHrG+NI66pQE4A3+2uTpVuX+MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDA
1OHrG+NI66pQE4A3+2uTpVuX+NBgkqhkiG9w0BAQUF
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD 
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
PXFOS7+BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
PXFOS7+DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR
PXFOS7+sQ2OcZejF/Kjh7SHmM/NHIfSuraWJcayb4njNt8vKRYazfiFF8G2O7cOOe674KM9
TpMPay5Ei0HMRb1uQjRaFmxVd1RoKw==
-END CERTIFICATE- 

-Original Message-
From: Rene Hollan
Sent: Thursday, March 12, 2009 3:01 PM
To: 'openssl-users@openssl.org'
Subject: Can't recognize intermediate CA

I'm tearing my hair out trying to get an intermediate CA to be
recognized.

I have cacert.pem signing intcert.pem signing (well, resigning),
yahoo.pem

Openssl verify verifiies intcert.pem against cacert.pem, but won't
verify yahoo.pem against intcert.pem.

Subject/issuer match. AKID dirname and issuer subject match, AKID serial
number and issuer serial number match. AKID and issuer SKID match. Basic
Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
measure) cert. Key usage CertSign and CRLSign on both root and
intermediate cert.

Can anyone see what is wrong? I'm including PEM versions of these certs.

Cacert.pem:

-BEGIN CERTIFICATE-
MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALiK8GZlT0zZJkfGpwXfiQhO

Can't recognize intermediate CA

I'm tearing my hair out trying to get an intermediate CA to be
recognized.

I have cacert.pem signing intcert.pem signing (well, resigning),
yahoo.pem

Openssl verify verifiies intcert.pem against cacert.pem, but won't
verify yahoo.pem against intcert.pem.

Subject/issuer match. AKID dirname and issuer subject match, AKID serial
number and issuer serial number match. AKID and issuer SKID match. Basic
Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
measure) cert. Key usage CertSign and CRLSign on both root and
intermediate cert.

Can anyone see what is wrong? I'm including PEM versions of these certs.

Cacert.pem:

-BEGIN CERTIFICATE-
MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
AvScpmyMe2Mb
-END CERTIFICATE-


Intcert.pem:

-BEGIN CERTIFICATE-
MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC
B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz
QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN
mjwXr099i5XcIvlfR9v677Q=
-END CERTIFICATE-


Yahoo.pem:

-BEGIN CERTIFICATE- 
MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj 
ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg 
1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl
MRUwEwYDVQQDFgxSZXNpZ25pbmdfQ0GCCQCLda47dCCwQDANBgkqhkiG9w0BAQUF 
AAOCAQEAMS8EfpQrc/5ymRU4bMH8zg/ADJ2mAk8+BsHMBIaWBMDycVHMJUImmnfD 
PXFOS7+XnDLE7fVwgiNcY/k7223s6BMI/AMmtBg8qm7sR9V+7fv9Jq7BGWgmUPdG
BkqWYmfsd2uVei/rZchAvGiFc4hEVbt7s6pazASAFYN/RectfQtx8LBdJVC78SfF
DuO+l/hclIGJec5uzlpCenVydGVgToddvpV7Qg4Z+Rap2xiXx63KugGSRjA/1tnR
sQ2OcZejF/Kjh7SHmM

RE: Can't recognize intermediate CA


the cacert has pathlen:1 in its X509v3 Basic Constraints


 Subject: Can't recognize intermediate CA
 Date: Thu, 12 Mar 2009 15:00:47 -0700
 From: rene.hol...@watchguard.com
 To: openssl-users@openssl.org

 I'm tearing my hair out trying to get an intermediate CA to be
 recognized.

 I have cacert.pem signing intcert.pem signing (well, resigning),
 yahoo.pem

 Openssl verify verifiies intcert.pem against cacert.pem, but won't
 verify yahoo.pem against intcert.pem.

 Subject/issuer match. AKID dirname and issuer subject match, AKID serial
 number and issuer serial number match. AKID and issuer SKID match. Basic
 Constraints CA:TRUE, pathlen:1 on both root and intermediate (for good
 measure) cert. Key usage CertSign and CRLSign on both root and
 intermediate cert.

 Can anyone see what is wrong? I'm including PEM versions of these certs.

 Cacert.pem:

 -BEGIN CERTIFICATE-
 MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
 CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
 YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
 hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
 ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
 AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
 eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
 iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
 mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
 VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
 MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
 MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
 RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
 dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
 FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
 bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
 r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
 AvScpmyMe2Mb
 -END CERTIFICATE-


 Intcert.pem:

 -BEGIN CERTIFICATE-
 MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
 IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
 d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
 AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
 wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
 COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
 qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
 NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
 yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
 BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
 dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
 b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
 DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
 ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
 kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
 NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC
 B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz
 QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN
 mjwXr099i5XcIvlfR9v677Q=
 -END CERTIFICATE-


 Yahoo.pem:

 -BEGIN CERTIFICATE-
 MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3
 DQEBBQUAMEwxIDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYD
 VQQLEwhGaXJld2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMB4XDTA2MDEwNDE3
 MDkwNloXDTExMDEwNDE3MDkwNloweDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh
 bGlmb3JuaWExFDASBgNVBAcTC1NhbnRhIENsYXJhMRQwEgYDVQQKFAtZYWhvbyEg
 SW5jLjEOMAwGA1UECxMFWWFob28xGDAWBgNVBAMTD2xvZ2luLnlhaG9vLmNvbTCB
 nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA484iMII/1qq0eEs8UQ1B4HHWD9Qj
 ZVS1z9BfCtfJBK3L5+xH+ZJayxiZW9zhRgMPhLhqDg8zyK3ah18A3JmbMHRu1QOg
 1OHrG+NI66pQE4A3+2uTpVuX+IauLDtfEg8SDvnJLOItIhvj/pBky0lP0zQwpDbz
 DDxauMfmQj2QhGcCAwEAAaOBzzCBzDAOBgNVHQ8BAf8EBAMCBPAwHQYDVR0lBBYw
 FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSbi+W7qyiacBd5dbiLIySj
 9WC0YDB8BgNVHSMEdTBzgBSEEcoe9bZDB56/eMMA5AEZnu0bR6FQpE4wTDEgMB4G
 A1UEChYXV2F0Y2hHdWFyZF9UZWNobm9sb2dpZXMxETAPBgNVBAsTCEZpcmV3YXJl

RE: Can't recognize intermediate CA

I tried it with no (i.e. infinite) pathlen specified in cacert.pem. Same
effect.

Am I wrong in understanding that pathlen:0 implies no intermediate CAs
and pathlen:1 implies at most one intermediate CA (as is the case here)?

I used openssl with the intermediate CA to sign a separate cert, which
had a AKID keyid but no issuer, and that chain recongizes fine.

Could the problem be the fact that yahoo.pem has an AKID keyid AND
issuer? (onr or the other is sufficient, but I could find nothing that
said that both were illegal).
 

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen
Sent: Thursday, March 12, 2009 3:49 PM
To: openssl-users@openssl.org
Subject: RE: Can't recognize intermediate CA


the cacert has pathlen:1 in its X509v3 Basic Constraints


 Subject: Can't recognize intermediate CA
 Date: Thu, 12 Mar 2009 15:00:47 -0700
 From: rene.hol...@watchguard.com
 To: openssl-users@openssl.org

 I'm tearing my hair out trying to get an intermediate CA to be 
 recognized.

 I have cacert.pem signing intcert.pem signing (well, resigning), 
 yahoo.pem

 Openssl verify verifiies intcert.pem against cacert.pem, but won't 
 verify yahoo.pem against intcert.pem.

 Subject/issuer match. AKID dirname and issuer subject match, AKID 
 serial number and issuer serial number match. AKID and issuer SKID 
 match. Basic Constraints CA:TRUE, pathlen:1 on both root and 
 intermediate (for good
 measure) cert. Key usage CertSign and CRLSign on both root and 
 intermediate cert.

 Can anyone see what is wrong? I'm including PEM versions of these
certs.

 Cacert.pem:

 -BEGIN CERTIFICATE-
 MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
 CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
 YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
 hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
 ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
 AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
 eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
 iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
 mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
 VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
 MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
 MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
 RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
 dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
 FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
 bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
 r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
 AvScpmyMe2Mb
 -END CERTIFICATE-


 Intcert.pem:

 -BEGIN CERTIFICATE-
 MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
 IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
 d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
 AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
 wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
 COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
 qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
 NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
 yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
 BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
 dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
 b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
 DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
 ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
 kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m
 NQxsY8NqwWswXHtRLLWJgAzZKWeN1PYMGgRmmGaH2lPYGT0xcpRuZfhTE5HlJ9VC
 B3hV3JMD+VzPTzzcFm3gCCyR+dgNI0FmpoxtJzlirVj4BjHqTl+v4uhaX/wCgBvz
 QcAWftj4GiemnficByogBS3QdbDwQGephQX2qySXzv0o8+qOV+RNMdPHH1T4o/tN
 mjwXr099i5XcIvlfR9v677Q=
 -END CERTIFICATE-


 Yahoo.pem:

 -BEGIN CERTIFICATE-
 MIIDojCCAoqgAwIBAgIYANIyCa0j0xQjIXTkDX+dYhOXhmM6BaBMMA0GCSqGSIb3

RE: Can't recognize intermediate CA



 I tried it with no (i.e. infinite) pathlen specified in cacert.pem. Same
 effect.

 Am I wrong in understanding that pathlen:0 implies no intermediate CAs
 and pathlen:1 implies at most one intermediate CA (as is the case here)?

i believe you're right: the pathlen isnt the problem. (i just read 
http://www.openssl.org/docs/apps/x509v3_config.html#Basic_Constraints_ again.)


 I used openssl with the intermediate CA to sign a separate cert, which
 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND
 issuer? (onr or the other is sufficient, but I could find nothing that
 said that both were illegal).

using -verbose and -issuer_checks showed, along with error 29:
error 31 at 0 depth lookup:authority and issuer serial number mismatch

so i compared the serial numbers and the key id's. they looked ok to me. so at 
this point, i dont have any ideas.



 -Original Message-
 From: owner-openssl-us...@openssl.org
 [mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen
 Sent: Thursday, March 12, 2009 3:49 PM
 To: openssl-users@openssl.org
 Subject: RE: Can't recognize intermediate CA


 the cacert has pathlen:1 in its X509v3 Basic Constraints

 
 Subject: Can't recognize intermediate CA
 Date: Thu, 12 Mar 2009 15:00:47 -0700
 From: rene.hol...@watchguard.com
 To: openssl-users@openssl.org

 I'm tearing my hair out trying to get an intermediate CA to be
 recognized.

 I have cacert.pem signing intcert.pem signing (well, resigning),
 yahoo.pem

 Openssl verify verifiies intcert.pem against cacert.pem, but won't
 verify yahoo.pem against intcert.pem.

 Subject/issuer match. AKID dirname and issuer subject match, AKID
 serial number and issuer serial number match. AKID and issuer SKID
 match. Basic Constraints CA:TRUE, pathlen:1 on both root and
 intermediate (for good
 measure) cert. Key usage CertSign and CRLSign on both root and
 intermediate cert.

 Can anyone see what is wrong? I'm including PEM versions of these
 certs.

 Cacert.pem:

 -BEGIN CERTIFICATE-
 MIIEVTCCAz2gAwIBAgIJAIt1rjt0ILA+MA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTM3MDNaFw0xMjAzMTEyMTM3MDNaMHQx
 CzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29i
 YXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZI
 hvcNAQkBFgtmb29AYmFyLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
 ggEBALiK8GZlT0zZJkfGpwXfiQhO++76F6PJGczjeKXv+b7SdIhBIKlMZvNHlM1z
 96QQI8rrSnlZpKi7MXwZZaSVNUF8cas1OrfkOJ2Epb2/HmgbqXMKCIDVxvN/kHcP
 AFgPwlWx7gzYCPzmUcHl1t+8BesiFuMR8gvjB1CuKTbOgM3YgI08pOmon+zXkbz2
 Jr8GhBgTMuCowL7GbrF9zUOKVUeNemc1zRYtIvlaKpk4ieCPcvSdXu4I6kPOkUlM
 eBkKU+yEHkAzeLlzryOlbx+dbl+yUexNdUXXXfTa+3OEzFS+4m+UJxS/czHvtb4P
 iOO8CAspuvVKoSm4vFMr09TKP7kCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUGkDcZzhR
 mtzShXaKRqteehN6ZFswgaYGA1UdIwSBnjCBm4AUGkDcZzhRmtzShXaKRqteehN6
 ZFuheKR2MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYD
 VQQKEwZGb29iYXIxDzANBgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFy
 MRowGAYJKoZIhvcNAQkBFgtmb29AYmFyLmNvbYIJAIt1rjt0ILA+MA8GA1UdEwQI
 MAYBAf8CAQEwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBhmhGBn+fI
 RtociIKU8DsUgs8LGrM7pNt+ST2L2qIxemVACO1eXTGqrvKzh6B3M5P+q9rN2QeR
 dGYh+JqXGo6nYkaTGZPW3oVfcXjcV/ewpkWgR15uGKpZqfNgj4NUDTnk5IOlYn6C
 FCnwR8ZQ9R8zGpT8ihYWcIfqQmix+t76KmxE6nQ5RyYO1qOYzHWGHZ0oQCU3/15v
 bcJqqgCUjC8b3sHE4AduYB92Dfh1b2YjfB8Em0eP5wyzwPVVq+RI89pg6RqMj5ue
 r0MPfMcp1E98zibSFeBYVjV0yyxPpg7IRDZmaI3HveBYfV1fDwg0fHeNrBn7dy3I
 AvScpmyMe2Mb
 -END CERTIFICATE-


 Intcert.pem:

 -BEGIN CERTIFICATE-
 MIIELTCCAxWgAwIBAgIJAIt1rjt0ILBAMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
 BAYTAlVTMRMwEQYDVQQIEwpXYXNoaW5ndG9uMQ8wDQYDVQQKEwZGb29iYXIxDzAN
 BgNVBAsTBmZvb2JhcjESMBAGA1UEAxMJRm9vIEIuIEFyMRowGAYJKoZIhvcNAQkB
 Fgtmb29AYmFyLmNvbTAeFw0wOTAzMTIyMTQxNDVaFw0xMDAzMTIyMTQxNDVaMEwx
 IDAeBgNVBAoWF1dhdGNoR3VhcmRfVGVjaG5vbG9naWVzMREwDwYDVQQLEwhGaXJl
 d2FyZTEVMBMGA1UEAxYMUmVzaWduaW5nX0NBMIIBIjANBgkqhkiG9w0BAQEFAAOC
 AQ8AMIIBCgKCAQEA8zXi919osAnB6xIjSfvzvXJe6a+0p6RreKZ2kt3gr7rrlUZN
 wYg92+PpBx7ufNxZWZYaDYnXttZUx9hFJognz5iOkIGf4Iq0rZOc2EPYH+NiCtP/
 COd++s8LSX+P258EHiTkPP3spANTttfn7pltdjoysJDWXrUIlBhmMeB/zpSRBIXX
 qeXjZ5qvp5IGGDMfg9whv7Ct+awiuf1E98bCoYEfbpywFO7os67lYtWQvxRBd2yc
 NUvNFssNGFmYj2JEixqdCpcPWXxwMNYRbmwkPiB9rQnaykOrzzWJ03PXTwT+iM6T
 yk60Y+bN5hSmM3z0dQF0HS4WZ2uZUUWp5ZrwmQIDAQABo4HpMIHmMB0GA1UdDgQW
 BBSEEcoe9bZDB56/eMMA5AEZnu0bRzCBpgYDVR0jBIGeMIGbgBQaQNxnOFGa3NKF
 dopGq156E3pkW6F4pHYwdDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCldhc2hpbmd0
 b24xDzANBgNVBAoTBkZvb2JhcjEPMA0GA1UECxMGZm9vYmFyMRIwEAYDVQQDEwlG
 b28gQi4gQXIxGjAYBgkqhkiG9w0BCQEWC2Zvb0BiYXIuY29tggkAi3WuO3QgsD4w
 DwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEB
 ABxzGFfezOPSQUZW4BkgCKlTM8heLIP48bXL8PHR+4ZW/C3FoaPwb8oCI2EMJAEq
 kPHDr2NTtZ++Nx+1tVFpkSxfSBuC/gHjAlewk3owPbLmwDpIf7MPMX0iKgfUeC+m

RE: Can't recognize intermediate CA



 I used openssl with the intermediate CA to sign a separate cert, which
 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND
 issuer? (onr or the other is sufficient, but I could find nothing that
 said that both were illegal).

it might be a bug in openssl X509_check_issued() function.

im using openssl 0.9.8i.

line 650 in v3_purp.c:

if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;

nm is the DirName thing in the subject cert's AKID, ie 
/O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
and issuer is the intermediate CA cert, so its X509_get_issuer_name(issuer) 
will be name of root CA.
so the comparsion will fail, and you get the error.

looks like it should be X509_get_subject_name(issuer)
_
Windows Live™ Groups: Create an online spot for your favorite groups to meet.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA


 I used openssl with the intermediate CA to sign a separate cert, which
 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND
 issuer? (onr or the other is sufficient, but I could find nothing that
 said that both were illegal).

 it might be a bug in openssl X509_check_issued() function.

 im using openssl 0.9.8i.

 line 650 in v3_purp.c:

 if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
 return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;

 nm is the DirName thing in the subject cert's AKID, ie 
 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
 and issuer is the intermediate CA cert, so its 
 X509_get_issuer_name(issuer) will be name of root CA.
 so the comparsion will fail, and you get the error.

 looks like it should be X509_get_subject_name(issuer)


$ ./openssl version
OpenSSL 0.9.8i 15 Sep 2008
$
$ ./openssl verify -CApath cas cas/int.pem
cas/int.pem: OK
$
$ ./openssl verify -CApath cas yahoo.pem
yahoo.pem: /C=US/ST=California/L=Santa Clara/O=Yahoo! 
Inc./OU=Yahoo/CN=login.yahoo.com
error 20 at 0 depth lookup:unable to get local issuer certificate
$
$
$ gdb --args ./openssl verify -CApath cas yahoo.pem
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
(gdb)
(gdb) b v3_purp.c:630
Breakpoint 1 at 0x812d0e7: file v3_purp.c, line 630.
(gdb) b v3_purp.c:651
Breakpoint 2 at 0x812d186: file v3_purp.c, line 651.
(gdb) r
Starting program: ./openssl verify -CApath cas yahoo.pem

Breakpoint 2, X509_check_issued (issuer=0x8204e68, subject=0x8204760) at 
v3_purp.c:651
651 return 
X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;
(gdb) p nm
$1 = (X509_NAME *) 0x820bf18
(gdb) p X509_NAME_oneline(nm,0,0)
$2 = 0x820c0f8 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
(gdb) p issuer
$3 = (X509 *) 0x8204e68
(gdb) set nm=X509_get_issuer_name(issuer)
(gdb) p nm
$4 = (X509_NAME *) 0x8206310
(gdb) p X509_NAME_oneline(nm,0,0)
$5 = 0x820c208 /C=US/ST=Washington/O=Foobar/OU=foobar/CN=Foo B. 
Ar/emailaddress=...@bar.com
(gdb) set nm=X509_get_subject_name(issuer)
(gdb) p nm
$6 = (X509_NAME *) 0x82083b0
(gdb) p X509_NAME_oneline(nm,0,0)
$7 = 0x820c318 /O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
(gdb)


_
Windows Live™: Life without walls.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA

Yeah, I just noticed that.

I've been comparing how my intermediate CA resigned an existing cert
(it's part of a proxy that decrypts, examines, and reencrypts -- the
downstream client sharing a trust hierarchy with the intermediate
resigning CA) with what OpenSSL ca ... does.

OpenSSL ca ... actually puts the issuer of the issuer into the AKID
issuer field of the signed cert, along with the issuer serial number.
When the issuer is a root ca, it is it's own issuer, so the issuer
(which is what my resigning code was using), and issuer's issuer are the
same. But, when the issuer is an intermediate CA, they are different.
  
So, either I'm doing it wrong, or OpenSSL ca ... Is doing it wrong (but
consistent with how OpenSSL verify ... checks).

At this point, I think the error is mine. At least browsers accept the
cert when OpenSSL signs it with an intermediate CA, and not when I do.

Think about it: the purpose of the AKID is to identify the public key of
the signer, either by matching the SKID of the signer, or some other
means of identifying the signer. Well, the signer's serial number is
unique within those issued by IT'S signer, so the combination of IT's
signer and IT's serial number should be probabilistically unique.

This whole SKID/AKID mess comes about because issuer and subject DNs are
not guaranteed to be globally unique, but the combination of issuer's
issuer DN, and issuer's serial number within the issuer's issuer's DN
are statistically more so. (Without SKID/AKID, one would have to verify
a prospective issuer by unhashing the signature with the issuer's public
key, which is arguably more computationally expensive that comparing
SKID and AKID. One should still do this anyway, but the SKID/AKID check
preemptively eliminates the wrong issuer).

Sigh. X500 looks like a royal designed by non-technical committee
mess.

Thanks for the help, now excuse me while I make a code change.

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Giang Nguyen
Sent: Thursday, March 12, 2009 4:56 PM
To: openssl-users@openssl.org
Subject: RE: Can't recognize intermediate CA



 I used openssl with the intermediate CA to sign a separate cert, which

 had a AKID keyid but no issuer, and that chain recongizes fine.

 Could the problem be the fact that yahoo.pem has an AKID keyid AND 
 issuer? (onr or the other is sufficient, but I could find nothing that

 said that both were illegal).

it might be a bug in openssl X509_check_issued() function.

im using openssl 0.9.8i.

line 650 in v3_purp.c:

if(nm  X509_NAME_cmp(nm, X509_get_issuer_name(issuer)))
return X509_V_ERR_AKID_ISSUER_SERIAL_MISMATCH;

nm is the DirName thing in the subject cert's AKID, ie
/O=WatchGuard_Technologies/OU=Fireware/CN=Resigning_CA
and issuer is the intermediate CA cert, so its
X509_get_issuer_name(issuer) will be name of root CA.
so the comparsion will fail, and you get the error.

looks like it should be X509_get_subject_name(issuer)
_
Windows Live(tm) Groups: Create an online spot for your favorite groups
to meet.
http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Can't recognize intermediate CA

2009-03-12 Thread Dr. Stephen Henson

On Thu, Mar 12, 2009, Rene Hollan wrote:

 Yeah, I just noticed that.
 
 I've been comparing how my intermediate CA resigned an existing cert
 (it's part of a proxy that decrypts, examines, and reencrypts -- the
 downstream client sharing a trust hierarchy with the intermediate
 resigning CA) with what OpenSSL ca ... does.
 
 OpenSSL ca ... actually puts the issuer of the issuer into the AKID
 issuer field of the signed cert, along with the issuer serial number.
 When the issuer is a root ca, it is it's own issuer, so the issuer
 (which is what my resigning code was using), and issuer's issuer are the
 same. But, when the issuer is an intermediate CA, they are different.
   
 So, either I'm doing it wrong, or OpenSSL ca ... Is doing it wrong (but
 consistent with how OpenSSL verify ... checks).
 
 At this point, I think the error is mine. At least browsers accept the
 cert when OpenSSL signs it with an intermediate CA, and not when I do.
 
 Think about it: the purpose of the AKID is to identify the public key of
 the signer, either by matching the SKID of the signer, or some other
 means of identifying the signer. Well, the signer's serial number is
 unique within those issued by IT'S signer, so the combination of IT's
 signer and IT's serial number should be probabilistically unique.
 
 This whole SKID/AKID mess comes about because issuer and subject DNs are
 not guaranteed to be globally unique, but the combination of issuer's
 issuer DN, and issuer's serial number within the issuer's issuer's DN
 are statistically more so. (Without SKID/AKID, one would have to verify
 a prospective issuer by unhashing the signature with the issuer's public
 key, which is arguably more computationally expensive that comparing
 SKID and AKID. One should still do this anyway, but the SKID/AKID check
 preemptively eliminates the wrong issuer).
 
 Sigh. X500 looks like a royal designed by non-technical committee
 mess.
 
 Thanks for the help, now excuse me while I make a code change.
 

If it's any consolation you aren't alone with that, it gets commented on quite
often so much so in fact that it has an FAQ entry:

http://www.openssl.org/support/faq.html#USER15

You can just leave out the issuer+serial number combination from AKID too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA






Sincerely,

Giang Nguyen







 Date: Fri, 13 Mar 2009 00:22:56 +0100
 From: st...@openssl.org
 To: openssl-users@openssl.org
 Subject: Re: Can't recognize intermediate CA

 On Thu, Mar 12, 2009, Rene Hollan wrote:

 Yeah, I just noticed that.

 I've been comparing how my intermediate CA resigned an existing cert
 (it's part of a proxy that decrypts, examines, and reencrypts -- the
 downstream client sharing a trust hierarchy with the intermediate
 resigning CA) with what OpenSSL ca ... does.

 OpenSSL ca ... actually puts the issuer of the issuer into the AKID
 issuer field of the signed cert, along with the issuer serial number.
 When the issuer is a root ca, it is it's own issuer, so the issuer
 (which is what my resigning code was using), and issuer's issuer are the
 same. But, when the issuer is an intermediate CA, they are different.

 So, either I'm doing it wrong, or OpenSSL ca ... Is doing it wrong (but
 consistent with how OpenSSL verify ... checks).

 At this point, I think the error is mine. At least browsers accept the
 cert when OpenSSL signs it with an intermediate CA, and not when I do.

 Think about it: the purpose of the AKID is to identify the public key of
 the signer, either by matching the SKID of the signer, or some other
 means of identifying the signer. Well, the signer's serial number is
 unique within those issued by IT'S signer, so the combination of IT's
 signer and IT's serial number should be probabilistically unique.

 This whole SKID/AKID mess comes about because issuer and subject DNs are
 not guaranteed to be globally unique, but the combination of issuer's
 issuer DN, and issuer's serial number within the issuer's issuer's DN
 are statistically more so. (Without SKID/AKID, one would have to verify
 a prospective issuer by unhashing the signature with the issuer's public
 key, which is arguably more computationally expensive that comparing
 SKID and AKID. One should still do this anyway, but the SKID/AKID check
 preemptively eliminates the wrong issuer).

 Sigh. X500 looks like a royal designed by non-technical committee
 mess.

 Thanks for the help, now excuse me while I make a code change.


 If it's any consolation you aren't alone with that, it gets commented on quite
 often so much so in fact that it has an FAQ entry:

 http://www.openssl.org/support/faq.html#USER15


doh, that makes sense! thanks.

_
Hotmail® is up to 70% faster. Now good news travels really fast. 
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA

 Yup. That fixed it.. At least as far as openssl verify -CAfile
cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

Oddly, firefox still rejects the end cert, even though both cacert.pem
and intcert2.pem are in it's trust store. Is it possible that browsers
actually ignore intermediate CA certs in their trust store and expect
servers to provide them? That's the next thing for me to try (if only I
can remember how to do that with openssl... :-)).


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA


If it's any consolation you aren't alone with that, it gets commented on
quite often so much so in fact that it has an FAQ entry:

http://www.openssl.org/support/faq.html#USER15

You can just leave out the issuer+serial number combination from AKID
too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA

True, but (a) it doesn't hurt to have both, and (b) if  the issuer
doesn't have a SKID, AKID issuer/serial takes the place of an AKID
keyid.

-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA


You can just leave out the issuer+serial number combination from AKID
too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA

 Sigh.

Well, I added the intermediate CA to the cert chain sent by my proxy
(and verified this with wireshark).

OpenSSL s_client -CAfile cacert.pem -host login.yahoo.com -port 443
works and shows the trust chain.

But, Firefox, with cacert.pem loaded into it's trust store still
complains. :-(

 

-Original Message-
From: Rene Hollan 
Sent: Thursday, March 12, 2009 5:39 PM
To: 'openssl-users@openssl.org'
Subject: RE: Can't recognize intermediate CA

 Yup. That fixed it.. At least as far as openssl verify -CAfile
cacert.pem -untrusted intcert2.pem yahoo-x.pem goes.

Oddly, firefox still rejects the end cert, even though both cacert.pem
and intcert2.pem are in it's trust store. Is it possible that browsers
actually ignore intermediate CA certs in their trust store and expect
servers to provide them? That's the next thing for me to try (if only I
can remember how to do that with openssl... :-)).


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 12, 2009 4:23 PM
To: openssl-users@openssl.org
Subject: Re: Can't recognize intermediate CA


If it's any consolation you aren't alone with that, it gets commented on
quite often so much so in fact that it has an FAQ entry:

http://www.openssl.org/support/faq.html#USER15

You can just leave out the issuer+serial number combination from AKID
too.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL
project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

RE: Can't recognize intermediate CA