All certificates issued by a given signer must have different serial numbers. Having both be serial number 0 violates this constraint. (If you look at the serial number as being the 'primary key' into the database of issued certificates by a given authority, this constraint makes sense.)
-Kyle H On Tue, Sep 9, 2008 at 5:28 AM, Patrick Patterson <[EMAIL PROTECTED]> wrote: > Hi Silviu: > > On September 8, 2008 11:38:22 am Silviu VLASCEANU wrote: >> Thanks a lot for both answers, they were very helpful; however, it was >> easier for me to use Pierre's method. >> >> Although I managed to add the AKID, the verification of the endhost >> certificate's context with X509_verify_cert() says the certificate it's not >> YET valid and: >> >> X509_verify_cert failed: error:0906D06C:PEM routines:PEM_read_bio:no start >> line >> > How are you reading in the certificates? I believe this error is what happens > when there is no "----- BEGIN CERTIFICATE -----" line at the start of the > file being read. Since the file that you included has it, my guess is that > you are chopping the header and footer off somewhere. Don't do that :) If you > want anything other than a guess, you should post some additional code to > help us help you. > >> The upper certification path is OK, including the certificate of the >> issuer. I have attached both issuer and endhost certificate, if you have >> the time to take a look and tell me if you think something's wrong/missing! >> > A couple of things that I noticed in the "endhost" cert: > > 1: you are using md5 hashing for the Signature Algorithm - don't do that... > it's highly insecure - use SHA1 instead. > > 2: You should probably have a serial number - a serial number of 0 is not a > very good idea. > > 3: You should include the keyUsage extension and mark it critical. Since this > is an endhost, you may just want the value of "digitalSignature". Depending > on the use case, you should use the "best practice" for that type of device > or usage for inclusion of other values in both this extension, and the > extendedKeyUsage extension. > > 4: It is probably a good idea to include the CRL Distribution point > extension - your application may not know how to deal with it now, but it > may, over the lifetime of the certificate, be upgraded to deal with it as > more and more people are starting to "do PKI right" :) > > And in the "issuer" cert: > > 1: you are again using md5 hashing. > > 2: you REALLY should have a critical keyUsage extension with the > values "digitalSignature", "certSign" and "crlSign" > > 3: Why do you have the sbgp extension in a CA certificate? > > 4: AKI is not usually needed in a CA cert - after all, you already know and > have the signer of the cert - itself. > > 5: Your serial number is again 0 - as this is a duplicate of the endhost, it > would mean that if you revoked the endhost, you would also be revoking the > CA - probably not what you want. > > Have fun. > > -- > Patrick Patterson > President and Chief PKI Architect, > Carillon Information Security Inc. > http://www.carillon.ca > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
