The Authority Key ID extension - Openssl

This is a discussion on The Authority Key ID extension - Openssl ; Hi, Sorry to bother again, but I still haven't found how to add the Authority Key ID to a certificate, using openssl. Please, I need some help with this. The details are below. Thank you in advance, -- Silviu 2008/9/3 ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: The Authority Key ID extension

  1. The Authority Key ID extension

    Hi,

    Sorry to bother again, but I still haven't found how to add the Authority
    Key ID to a certificate, using openssl.
    Please, I need some help with this. The details are below.

    Thank you in advance,

    --
    Silviu

    2008/9/3 Silviu VLASCEANU

    > Hello everybody,
    >
    > I need to copy the Subject Key ID (SKID) from the CA certificate to the
    > Authority Key ID (AKID) of a new certificate.
    > I have extracted the SKID with
    >
    > AUTHORITY_KEYID *akid = X509_get_ext_d2i(ca_cert,
    > NID_subject_key_identifier, NULL, NULL);
    >
    > How can I "put" akid in an X509_EXTENSION so that I can add the latter to
    > a new certificate with X509_add_ext(x, ex_akid, -1) ?
    >
    > Thanks a lot,
    >
    > --
    > Silviu
    >



  2. Re: The Authority Key ID extension

    Silviu VLASCEANU wrote:
    > Hi,
    >
    > Sorry to bother again, but I still haven't found how to add the
    > Authority Key ID to a certificate, using openssl.
    > Please, I need some help with this. The details are below.
    >
    > Thank you in advance,
    >
    > --
    > Silviu
    >
    > 2008/9/3 Silviu VLASCEANU > >
    >
    > Hello everybody,
    >
    > I need to copy the Subject Key ID (SKID) from the CA certificate
    > to the Authority Key ID (AKID) of a new certificate.
    > I have extracted the SKID with
    >
    > AUTHORITY_KEYID *akid = X509_get_ext_d2i(ca_cert,
    > NID_subject_key_identifier, NULL, NULL);
    >
    > How can I "put" akid in an X509_EXTENSION so that I can add the
    > latter to a new certificate with X509_add_ext(x, ex_akid, -1) ?
    >
    > Thanks a lot,
    >
    > --
    > Silviu
    >

    In my case, i set aki to this string :
    "issuer:always,keyid:always".

    It will display :
    keyid:[...] // the subject key id (keyid of isser)
    DirName:[...] // the dn of issuer's issuer)
    serial:[...] // the serail of issuer' issuer.


    To set this aki, i use this code :
    X509V3_CTX ctx; // create a context
    X509V3_set_ctx(&ctx, issuer , son, NULL, NULL, 0);
    X509_EXTENSION* ex = X509V3_EXT_conf_nid(NULL, &ctx,
    NID_authority_key_identifier , (char*)"issuer:always,keyid:always"));
    X509_add_ext( son,ex, -1);

    with X509* issuer, * son;

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: The Authority Key ID extension

    On Mon, Sep 08, 2008, Silviu VLASCEANU wrote:

    > Hi,
    >
    > Sorry to bother again, but I still haven't found how to add the Authority
    > Key ID to a certificate, using openssl.
    > Please, I need some help with this. The details are below.
    >


    Two ways, one is manually the other using the extension configuration code.

    Manually you get SKID which is an ASN1_OCTETSTRING using X509_get_ext_d2i().
    Then you create an AUTHORITY_KEYID structure with AUTHORITY_KEYID_new(), set
    the keyid pointer from the return value above and finally add it to the other
    certificate using X509_add1_ext_i2d().

    The other way is outlined in doc/openssl.txt

    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-users@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: The Authority Key ID extension

    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 majordomo@openssl.org


  5. Re: The Authority Key ID extension

    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
    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 majordomo@openssl.org
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  6. Re: The Authority Key ID extension

    Hello,

    Sorry for the delay, I had some problem with... "delays" .
    I have carefully read all of the suggestions from Kyle and Patrick. However,
    the serial issue was the most flagrant, definitely and I have immediately
    defined one. Concerning the other suggestions (KU, EKU, AKI), I agree with
    them but the project that I work on is not specifically concerned; the
    purpose is only to test a network protocol.

    However, I managed to solve the problem which was not at all related to
    openSSL, not even to programming at all.
    I was verifying the endhost certificate immediately after it was generated
    on-the-fly on the issuer machine. The problem was that the clocks of the two
    machines have pronounced jitters (+/- 10 s/ week) so my certificate was
    getting verified before its validity date began, thus the "not yet valid"
    error.

    Thanks again for all your help, I really added it to my PKC knowledge.

    --
    Silviu


  7. Re: The Authority Key ID extension

    If you're getting pronounced jitter on your client machines, I'd
    suggest two things:

    1) install ntp clients on them, and
    2) create your client certificates with a notBefore date of (now - 10m).

    The concept of 'time' is that there is One True Time. The problem is
    that the One True Time is difficult to trust your client machines to
    have. (This is the same problem that Kerberos has, by the way.)

    -Kyle H

    On Wed, Sep 10, 2008 at 4:03 AM, Silviu VLASCEANU
    wrote:
    > Hello,
    >
    > Sorry for the delay, I had some problem with... "delays" .
    > I have carefully read all of the suggestions from Kyle and Patrick. However,
    > the serial issue was the most flagrant, definitely and I have immediately
    > defined one. Concerning the other suggestions (KU, EKU, AKI), I agree with
    > them but the project that I work on is not specifically concerned; the
    > purpose is only to test a network protocol.
    >
    > However, I managed to solve the problem which was not at all related to
    > openSSL, not even to programming at all.
    > I was verifying the endhost certificate immediately after it was generated
    > on-the-fly on the issuer machine. The problem was that the clocks of the two
    > machines have pronounced jitters (+/- 10 s/ week) so my certificate was
    > getting verified before its validity date began, thus the "not yet valid"
    > error.
    >
    > Thanks again for all your help, I really added it to my PKC knowledge.
    >
    > --
    > Silviu
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  8. Re: The Authority Key ID extension

    2008/9/11 Kyle Hamilton

    > If you're getting pronounced jitter on your client machines, I'd
    > suggest two things:
    >
    > 1) install ntp clients on them, and
    > 2) create your client certificates with a notBefore date of (now - 10m).
    >


    That's exactly what I did. In fact, I synchronize machines weekly, but I
    haven't expected the clock to work that bad... What was worse was that one
    clock goes faster, the other one slower, so it doubles the difference


    >
    > The concept of 'time' is that there is One True Time. The problem is
    > that the One True Time is difficult to trust your client machines to
    > have. (This is the same problem that Kerberos has, by the way.)
    >
    > -Kyle H
    >


    Thanks,

    --
    Silviu


+ Reply to Thread