Hi Ashok, If you have a look at the v3_purp.c,
You can follow following algorithm: 1. check issuer name, if okay then proceed or exit. 2. check akid,.... 3. check the key usage ... (if the issuer certificate in the chain for a subject under consideration is allowed to sign or not), 4. check the path length constraint., and check for proxy certificates. As far as understood from openssl source code, it checks the akid only if it is present in the certificate otherwise it only depends on the subject name and issuer name match. Of course, at the end you need to verify the signature. But thats not the part of the certificate chain formation. On Mon, Jul 23, 2012 at 10:06 AM, Ashok C <ash....@gmail.com> wrote: > Thanks Sukalp, > > But I would like confirmation for the algorithm also. > Whether SKI/AKI related checks are sufficient for the chain formation, or > if anything else needs to be checked. > > -- > Ashok > > > On Mon, Jul 23, 2012 at 12:54 PM, Sukalp Bhople <bsuk...@gmail.com> wrote: > >> Hi, >> >> You can have a look at following files from openssl source code. >> >> 1. ssl_cert.c (around line number 626) >> 2. x509_vfy.c (around line number 153) >> 3. v3_purp.c (around line number 700). >> >> good luck! >> >> On Mon, Jul 23, 2012 at 8:41 AM, Ashok C <ash....@gmail.com> wrote: >> >>> 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 >>> >>> >> >> >> -- >> Regards, >> *Sukalp Bhople.* >> >> > -- Regards, *Sukalp Bhople.*
