Re: X509 V1 version info - Openssl

This is a discussion on Re: X509 V1 version info - Openssl ; The version field is offset by one. So, 0=v1, 1=v2, 2=v3 Frans. On Thu, 2008-08-28 at 12:21 +0530, Madhusudhan reddy wrote: > Hi All, > > I am newbie to OpenSSL. I am facing problem verifying root > certificate version ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Re: X509 V1 version info

  1. Re: X509 V1 version info

    The version field is offset by one. So, 0=v1, 1=v2, 2=v3

    Frans.

    On Thu, 2008-08-28 at 12:21 +0530, Madhusudhan reddy wrote:
    > Hi All,
    >
    > I am newbie to OpenSSL. I am facing problem verifying root
    > certificate version X509V1. While debugging found the signature
    > verification is not matching, it is because the calculated hash value
    > is not correct for the root certificate.
    >
    > And observed the version field X509->cert_info->version in
    > X509 certificate is NULL. The wrong hash value is because of version
    > field? Is something i am missing?
    >
    > I am attaching the root Certificate with the mail.
    >
    > Any help in this is greately appreciated.
    >
    > Thanks,
    > Madhu
    >



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


  2. Re: [openssl-users] Re: X509 V1 version info

    Hi,

    Hodie Kal. Sep. MMVIII est, Madhusudhan reddy scripsit:
    > Thanks for the reply. What i mean here is while loading X509
    > V1 certificate using the API "PEM_read_bio_X509_AUX(), the verisn filed
    > itself is null, not the value. Pls check the attached .jpg for the screen
    > shot.


    The version field is defined as:
    version [0] EXPLICIT Version DEFAULT v1

    The Version type is defined as:
    Version ::= INTEGER { v1(0), v2(1), v3(2) }

    DEFAULT implies OPTIONAL, and if this field is absent, then it has to
    be considered a version 1 certificate.

    I saved your certificate (a VeriSign one, it seems) to a file, and
    checked its signature:
    openssl verify -CAfile rootv1.pem rootv1.pem
    which replied "Ok".
    Do you have a better example of a "bad" certificate?

    --
    Erwann ABALEA
    -----
    I can't be stupid, I completed third grade!
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    User Support Mailing List openssl-users@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: [openssl-users] Re: X509 V1 version info

    Hello someone there, i stuck at the problem from quite some time.

    Could you guys help me in this? A small help in this regard will greately
    appreciated.

    Thank you very much.

    -Madhu

    On 9/1/08, Madhusudhan reddy wrote:
    >
    > Hi,
    >
    > Thanks for reply.
    >
    > Yes, it is verign certificate. Even though version info NULL
    > (X509->cert_info->version == NULL), the certifiate verified as valid, the
    > hash creation is equal to the hash in the certificate. I observed, for some
    > X509 V1 certificate the version field is NULL, and for some it is not NULL.
    > Here Iam attacheing 2 certificates in PEM format. For the cert
    > "test_root4.pem" the version fiels is NULL and for the cert "test_root5.pem"
    > version field is not NULL.
    >
    > But both the certificates verified valid while debugging.
    >
    > I couldn't guess why verison info NULL for some certs?
    >
    > Thanks,
    > Madhu
    >
    >
    >
    > On 9/1/08, Erwann ABALEA wrote:
    >>
    >> Hi,
    >>
    >> Hodie Kal. Sep. MMVIII est, Madhusudhan reddy scripsit:
    >> > Thanks for the reply. What i mean here is while loading

    >> X509
    >> > V1 certificate using the API "PEM_read_bio_X509_AUX(), the verisn

    >> filed
    >> > itself is null, not the value. Pls check the attached .jpg for the

    >> screen
    >> > shot.

    >>
    >> The version field is defined as:
    >> version [0] EXPLICIT Version DEFAULT v1
    >>
    >> The Version type is defined as:
    >> Version ::= INTEGER { v1(0), v2(1), v3(2) }
    >>
    >> DEFAULT implies OPTIONAL, and if this field is absent, then it has to
    >> be considered a version 1 certificate.
    >>
    >> I saved your certificate (a VeriSign one, it seems) to a file, and
    >> checked its signature:
    >> openssl verify -CAfile rootv1.pem rootv1.pem
    >> which replied "Ok".
    >> Do you have a better example of a "bad" certificate?
    >>
    >> --
    >> Erwann ABALEA
    >> -----
    >> I can't be stupid, I completed third grade!
    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> User Support Mailing List openssl-users@openssl.org
    >> Automated List Manager majordomo@openssl.org
    >>

    >
    >
    >



  4. Re: [openssl-users] Re: X509 V1 version info

    Honestly, I'm not sure. DER says that there is One True Encoding for
    any given certificate, and I think (but am not sure) that part of it
    is that "optional" parameters are not an option if the intended values
    match the defaults.

    I would guess that one of these is actually in violation of the rules,
    but I'm not enough of an expert on BER/DER encoding to be able to know
    for certain.

    -Kyle H

    On Mon, Sep 1, 2008 at 5:34 AM, Madhusudhan reddy
    wrote:
    > Hi,
    >
    > Thanks for reply.
    >
    > Yes, it is verign certificate. Even though version info NULL
    > (X509->cert_info->version == NULL), the certifiate verified as valid, the
    > hash creation is equal to the hash in the certificate. I observed, for some
    > X509 V1 certificate the version field is NULL, and for some it is not NULL.
    > Here Iam attacheing 2 certificates in PEM format. For the cert
    > "test_root4.pem" the version fiels is NULL and for the cert "test_root5.pem"
    > version field is not NULL.
    >
    > But both the certificates verified valid while debugging.
    >
    > I couldn't guess why verison info NULL for some certs?
    >
    > Thanks,
    > Madhu
    >
    >
    >
    > On 9/1/08, Erwann ABALEA wrote:
    >>
    >> Hi,
    >>
    >> Hodie Kal. Sep. MMVIII est, Madhusudhan reddy scripsit:
    >> > Thanks for the reply. What i mean here is while loading
    >> > X509
    >> > V1 certificate using the API "PEM_read_bio_X509_AUX(), the verisn
    >> > filed
    >> > itself is null, not the value. Pls check the attached .jpg for the
    >> > screen
    >> > shot.

    >>
    >> The version field is defined as:
    >> version [0] EXPLICIT Version DEFAULT v1
    >>
    >> The Version type is defined as:
    >> Version ::= INTEGER { v1(0), v2(1), v3(2) }
    >>
    >> DEFAULT implies OPTIONAL, and if this field is absent, then it has to
    >> be considered a version 1 certificate.
    >>
    >> I saved your certificate (a VeriSign one, it seems) to a file, and
    >> checked its signature:
    >> openssl verify -CAfile rootv1.pem rootv1.pem
    >> which replied "Ok".
    >> Do you have a better example of a "bad" certificate?
    >>
    >> --
    >> Erwann ABALEA
    >> -----
    >> I can't be stupid, I completed third grade!
    >> __________________________________________________ ____________________
    >> 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


  5. Re: [openssl-users] Re: X509 V1 version info

    Hello Experties there, could you pls help me?

    On Thu, Sep 4, 2008 at 3:45 PM, Kyle Hamilton wrote:

    > Honestly, I'm not sure. DER says that there is One True Encoding for
    > any given certificate, and I think (but am not sure) that part of it
    > is that "optional" parameters are not an option if the intended values
    > match the defaults.
    >
    > I would guess that one of these is actually in violation of the rules,
    > but I'm not enough of an expert on BER/DER encoding to be able to know
    > for certain.
    >
    > -Kyle H
    >
    > On Mon, Sep 1, 2008 at 5:34 AM, Madhusudhan reddy
    > wrote:
    > > Hi,
    > >
    > > Thanks for reply.
    > >
    > > Yes, it is verign certificate. Even though version info NULL
    > > (X509->cert_info->version == NULL), the certifiate verified as valid, the
    > > hash creation is equal to the hash in the certificate. I observed, for

    > some
    > > X509 V1 certificate the version field is NULL, and for some it is not

    > NULL.
    > > Here Iam attacheing 2 certificates in PEM format. For the cert
    > > "test_root4.pem" the version fiels is NULL and for the cert

    > "test_root5.pem"
    > > version field is not NULL.
    > >
    > > But both the certificates verified valid while debugging.
    > >
    > > I couldn't guess why verison info NULL for some certs?
    > >
    > > Thanks,
    > > Madhu
    > >
    > >
    > >
    > > On 9/1/08, Erwann ABALEA wrote:
    > >>
    > >> Hi,
    > >>
    > >> Hodie Kal. Sep. MMVIII est, Madhusudhan reddy scripsit:
    > >> > Thanks for the reply. What i mean here is while loading
    > >> > X509
    > >> > V1 certificate using the API "PEM_read_bio_X509_AUX(), the verisn
    > >> > filed
    > >> > itself is null, not the value. Pls check the attached .jpg for the
    > >> > screen
    > >> > shot.
    > >>
    > >> The version field is defined as:
    > >> version [0] EXPLICIT Version DEFAULT v1
    > >>
    > >> The Version type is defined as:
    > >> Version ::= INTEGER { v1(0), v2(1), v3(2) }
    > >>
    > >> DEFAULT implies OPTIONAL, and if this field is absent, then it has to
    > >> be considered a version 1 certificate.
    > >>
    > >> I saved your certificate (a VeriSign one, it seems) to a file, and
    > >> checked its signature:
    > >> openssl verify -CAfile rootv1.pem rootv1.pem
    > >> which replied "Ok".
    > >> Do you have a better example of a "bad" certificate?
    > >>
    > >> --
    > >> Erwann ABALEA
    > >> -----
    > >> I can't be stupid, I completed third grade!
    > >> __________________________________________________ ____________________
    > >> 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: [openssl-users] Re: X509 V1 version info


    > Hello Experties there, could you pls help me?


    What's the question exactly?


    > On Thu, Sep 4, 2008 at 3:45 PM, Kyle Hamilton wrote:


    >>Honestly, I'm not sure. DER says that there is One True Encoding for
    >>any given certificate, and I think (but am not sure) that part of it
    >>is that "optional" parameters are not an option if the intended values
    >>match the defaults.


    Nope. DER says nothing about how certificates specifically are encoded. The
    DER protocol is at a lower layer.

    >>I would guess that one of these is actually in violation of the rules,
    >>but I'm not enough of an expert on BER/DER encoding to be able to know
    >>for certain.


    >>-Kyle H


    It's not a violation of DER. The DER protocol has no idea that a missing
    version means version 1, nor could it. If the certificate protocol makes a
    field optional with a default value, having the field and not having the
    field are still different certificates as far as DER is concerned.

    If you think about it -- if you convert the certificate into text or XML,
    you would still have one certificate with a field present and one with it
    absent. On the other hand, if you allowed two different representations for
    the number 0, there would be no way to preserve that in another format.

    > I couldn't guess why verison info NULL for some certs?


    Someone opted not to put it in, and it is defined as optional. If I had to
    guess, I'd say an earlier version of the specification had no version field.
    IMO, it would have been smarter to make an omitted version mean version zero
    and not have any value for a version that means version zero -- but for some
    reason someone decided otherwise.

    This means if you express a certificate in any other format, you do have to
    distinguish between a certificate that is expressly version zero and one
    that does not specify a version.

    DS


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


  7. Re: [openssl-users] Re: X509 V1 version info

    Hi David,
    Thanks for the reply. I will try to explain my best the main
    problem i am facing.

    I ported OpenSSL 0.9.8g version on Symbian, and using OpenSSL to
    verify certificates. Following is the scenario to verify root certificates.

    1. Load root certificate from given file. (Loading using OpenSSL
    API)
    2. Load all stored root certificates from central repository
    (Loading using Symbian API).
    3. Converting certificate in Symbian format to OpenSSL X509
    structure.
    4. While verifying the certificate using X509_verify_cert(), it
    is failing.
    5. After debugging i found it is failing while comparing thumb
    print of 2 certificates( 1 loaded using OpenSSL API, 2 loaded using Symbian
    API and
    converted to OpenSSL X509).

    And the hash comparison fail because of invalid hash in the
    certificate loaded using Symbian API and converted to OpenSSL X509
    structure.
    And observed, the hash difference is because of version info
    present in Symbian load certificate. While debugging i put value Zero for
    version info, then
    verification succeeded.

    My question is, while converting certificate from Symbian format
    to OpenSSL X509 structure, what condition to check to make version info null
    or not null?

    Note: The certificate i mentioned is X509 V1.

    I hope i explained it. If any information required, pls ask me.

    Thanks,
    Madhu



    On Thu, Sep 11, 2008 at 10:32 AM, David Schwartz wrote:

    >
    > > Hello Experties there, could you pls help me?

    >
    > What's the question exactly?
    >
    >
    > > On Thu, Sep 4, 2008 at 3:45 PM, Kyle Hamilton

    > wrote:
    >
    > >>Honestly, I'm not sure. DER says that there is One True Encoding for
    > >>any given certificate, and I think (but am not sure) that part of it
    > >>is that "optional" parameters are not an option if the intended values
    > >>match the defaults.

    >
    > Nope. DER says nothing about how certificates specifically are encoded. The
    > DER protocol is at a lower layer.
    >
    > >>I would guess that one of these is actually in violation of the rules,
    > >>but I'm not enough of an expert on BER/DER encoding to be able to know
    > >>for certain.

    >
    > >>-Kyle H

    >
    > It's not a violation of DER. The DER protocol has no idea that a missing
    > version means version 1, nor could it. If the certificate protocol makes a
    > field optional with a default value, having the field and not having the
    > field are still different certificates as far as DER is concerned.
    >
    > If you think about it -- if you convert the certificate into text or XML,
    > you would still have one certificate with a field present and one with it
    > absent. On the other hand, if you allowed two different representations for
    > the number 0, there would be no way to preserve that in another format.
    >
    > > I couldn't guess why verison info NULL for some certs?

    >
    > Someone opted not to put it in, and it is defined as optional. If I had to
    > guess, I'd say an earlier version of the specification had no version
    > field.
    > IMO, it would have been smarter to make an omitted version mean version
    > zero
    > and not have any value for a version that means version zero -- but for
    > some
    > reason someone decided otherwise.
    >
    > This means if you express a certificate in any other format, you do have to
    > distinguish between a certificate that is expressly version zero and one
    > that does not specify a version.
    >
    > DS
    >
    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > User Support Mailing List openssl-users@openssl.org
    > Automated List Manager majordomo@openssl.org
    >



+ Reply to Thread