Also adding openSSL community into loop.
Thanks Dave. But main use case for me is the trust anchor update case.
I have a certain requirement which goes like this:
I have a client application which runs on my machine and it will attempt to
connect to multiple remote servers.
*At time T0:*
Client has old root. All servers have old end entity, connection goes fine.
*At time T1:*
Trust anchor updates itself and my client gets hold of the new root. But at
the same time it will not delete the old root since some servers would not
yet have procured the new end entity from the new root.
At this time, both roots would be present in my trust store. And I will
need to form the right certificate chain for a display command which should
display: new EE--new root. And not new EE--old root. For this, I would
need the AKI/SKI related checks. Since the issuer-id subject-name fields of
both old as well as new root would be same.
And regarding the some even don't have AKI/SKI, I read the RFC and it
mandates the presence of these extensions in all conforming CAs.
--
Ashok
On Fri, Jul 27, 2012 at 4:18 AM, Dave Thompson dthomp...@prinpay.comwrote:
**
I'm not certain that actually works as described.
I see the checks in crypto/x509/x509_vfy.c and crypto/x509v3/v3_purp.c,
but the 'search for parent' part has multiple options spread over several
sourcefiles --
the standard ways are to look in a file commonly designated CAfile and/or
a directory commonly designated CApath, but there are several ways to
extend this.
There are comments on x509_lu.c _get1_issuer, but I'm not sure if/when
they apply.
It has never been an issue for me, because all the CAs I've seen
have distinct DN's for each cert they issue, i.e. they never need
to disambiguate using AKI/SKI. And some don't even *have* AKI/SKI.
Good luck.
--
*From:* Ashok C [mailto:ash@gmail.com]
*Sent:* Thursday, 26 July, 2012 02:08
*To:* Dave Thompson
*Subject:* Fwd: Forming the correct chain for an end entity certificate
Reg.
Hi Dave,
Could you please help me on this?
--
Ashok
-- Forwarded message --
From: Ashok C ash@gmail.com
Date: Mon, Jul 23, 2012 at 12:11 PM
Subject: Forming the correct chain for an end entity certificate Reg.
To: openssl-users@openssl.org
Hi,
I have a requirement to form a correct certificate chain (for a server
application, to send to client).
Currently I was forming the chain using the issuer-id and subject name
combination alone.
Eg: The algorithm followed was:
Let End entity(server certificate) be called as 'E'. Root certificate as
'R' , and intermediate CA certificate be 'I'.
1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name and add it to chain. This is I. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Since for 'R' issuer-id and
subject-name are same, this is considered to be root and hence not added to
chain.
But, I find that this chain is not conclusive enough, as
subject-name==issuer-id is not a complete criteria for a root certificate
and also that I cannot be treated as issuer of E just because of the
success of the issuer-id/subject-name checks.
I read the openSSL verify man page and understood that checks related to
authority key identifier and subject key identifier are required to decide
upon the correct chain.
So I presume that the logic should be modified to look something like this:
1. Look up E's issuer-id. Let it be 'C=IN'. Chain at this step: E
2. Search trust store for CA certificate which has this 'C=IN' as
subject name. This is I. Check if authority key identifier of E is the
same as the subject key identifier of I. If this is true, add it to
chain. Chain at this step: E-I
3. Look at issuer-id of I and search trust store which has it as
subject-name. In this case I will find 'R'. Check if authority key
identifier of I is the same as the subject key identifier of R. 'R' can
be concluded as the root only if subject-name==issuer-id and
authority-key-identifier==subject-key-identifier.
Is this solution complete for a multi-level hierarchy? As of now, I do not
have to deal with cross-certification, though I am very interested to know
from you guys on the complications involved when that comes into the
picture. I understand there is RFC 4158 explaining this path formation, but
was wondering that needs to be read in detail only for the
cross-certification related parts.
Does openSSL have any sample implementation somewhere for this path
formation(subject-key/authority-key checks) which I could use for reference?
Thanks in advance.
Regards,
Ashok
