Alternate format for subjectKeyIdentifier and authorityKeyIdentifier
A question regarding KeyIdentifiers. rfc3280 section 4.2.1.2 describes Two common methods for generating key identifiers from the public key are: (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits). (2) The keyIdentifier is composed of a four bit type field with the value 0100 followed by the least significant 60 bits of the SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bit string bits). If my openssl config has subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always I get method (1) above. The Australian Standard AS 4539.1.2.1—2001 states: 6.3.2.2 Authority key identifier The authorityKeyIdentifier extension identifies the public key to be used to verify the signature in this certificate. It enables distinct keys used by the same CA to be distinguished (eg. as key updating occurs). Conforming certificates shall identify the key using the keyIdentifier field. The value of the keyIdentifier field should be a 64 bit OCTET STRING consisting of the hexadecimal value 0x4 (0100 in binary) followed by the 60 least significant bits of an SHA-1 hash of the DER-encoding of subjectPublicKey sub-field of subjectPublicKeyInfo. This extension shall be present in EE, CA, PCA and External Domain certificates, and shall not be marked critical. 6.3.2.3 Subject key identifier The subjectKeyIdentifier extension identifies the public key being certified. It enables distinct keys used by the same subject to be differentiated (eg. as key updating occurs). Conforming certificates shall identify the key using the keyIdentifier field as described in Clause 6.3.2.2. The subject key identifier shall be identical to the authority key identifier extension in any certificates issued by a CA using the identified public key. This extension shall be present in PAA, PCA, CA and External Domain certificates, and shall not be marked critical. Which is method (2). How can I get openssl to generate keyIdentifiers using method (2)? Regards, JZ John Zornig Specialist Systems Analyst Australian Access Federation Strategic Technologies Group Information Technology Services (ITS) The University of Queensland Brisbane Qld, 4072 Ph: +61 7 336 54288 Mob: +61 434 351 532 [EMAIL PROTECTED] http://www.uq.edu.au/~uqjzorni/
Cross-compile error
Hi, I'm using openssl-0.9.8e.tar.gz with my application under Linux. Now, i want to cross-compile my app for Windows and i must cross-compile openssl first, under mingw, but i can't. That is what i do: ./Configure mingw no-sha512 shared threads make CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib (Since the variables CC and RANLIB are not set by Configure properly) It stops after a few seconds with the following error: In file included from cversion.c:62: buildinf.h:6:4: #error "Windows builds (PLATFORM=mingw) use mk1mf.pl-createdMakefiles" make[1]: *** [cversion.o] Error 1 make[1]: se sale del directorio `/home/jor/devel/openssl-0.9.8ewin/crypto' make: *** [build_crypto] Error 1 What steps am i missing or what am i doing wrong? Thank you, -- Jorge Fernandez
Re: [openssl-users] Re: Changing the expiry date of a cert
Hodie XVI Kal. Nov. MMVII est, Jim Fox scripsit: > > This was a certificate authority certificate. As such, the renewal has to > have > the same key and DN as the original in order to continue being a CA > for previously signed certificates. You don't have to keep the same key, you just have to keep the same DN. -- Erwann ABALEA <[EMAIL PROTECTED]> - If you never try anything new, you'll miss out on many of life's great disappointments. Demotivators, 2002 calendar __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Segmentation fault in application creating too many threads.
At times The following traces as well are obtained:
(gdb) bt
#0 MD5_Init (c=0x0) at md5_dgst.c:75
#1 0x405b2a90 in init (ctx=0x0) at m_md5.c:73
#2 0x405afc91 in EVP_DigestInit_ex (ctx=0x8e29b44, type=0x4061f560,
impl=0x0) at digest.c:207
#3 0x403819f5 in ssl3_init_finished_mac (s=0x8e298c8) at s3_enc.c:521
#4 0x4037d0bc in ssl3_connect (s=0x8e298c8) at s3_clnt.c:232
#5 0x4038feb8 in SSL_connect (s=0x8e298c8) at ssl_lib.c:850
(gdb)
And:
#0 X509_VERIFY_PARAM_new () at x509_vpm.c:91
91 x509_vpm.c: No such file or directory.
in x509_vpm.c
(gdb) bt
#0 X509_VERIFY_PARAM_new () at x509_vpm.c:91
#1 0x4038d978 in SSL_new (ctx=0x42f8) at ssl_lib.c:297
#2 0x in ?? ()
(gdb)
And:
#0 SHA1_Init (c=0x0) at sha_locl.h:150
150 sha_locl.h: No such file or directory.
in sha_locl.h
(gdb) bt
#0 SHA1_Init (c=0x0) at sha_locl.h:150
#1 0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
#2 0x405afc91 in EVP_DigestInit_ex (ctx=0x8fb2ef4, type=0x4061f620,
impl=0x0) at digest.c:207
#3 0x40381a15 in ssl3_init_finished_mac (s=0x8fad288) at s3_enc.c:522
#4 0x4037d0bc in ssl3_connect (s=0x8fad288) at s3_clnt.c:232
#5 0x4038feb8 in SSL_connect (s=0x8fad288) at ssl_lib.c:850
On 10/18/07, Prabhu S <[EMAIL PROTECTED]> wrote:
>
> David,
>
> The OpenSSL version that I use is openssl-0.9.8e. Your guess about methods
> being called is right. It appears to be stack corruption.
>
> Gayathri,
>
> I don't suspect the gdb. I checked the CTX status in HASH_INIT (SHA_CTX
> *c) under stress , 'c' was indeed NULL and the application immediately
> dumped.
>
> Regards,
> Prabhu. S
>
>
> On 10/18/07, Gayathri S <[EMAIL PROTECTED]> wrote:
> >
> >
> > The stack trace showing a null sha1 transform kindof caught my attention
> > here, I wouldnt go by the the GDB call trace coz its obviously a memory
> > leak and the gdb stack could have been corrupted, many a times I see 0x0
> >
> > in the frames but when you actually try to print the ctx address it
> > would
> > be valid. CTX is definitely valid here,
> >
> > prabhu, earlier I was assuming you are using the linux sha1 in the
> > kernel
> > which is a loadable module, and I realise your just using plain openssl
> > from userspace and linking with libcrypto. Linux sha1 has a limitation
> > on
> > the sha1_tfm structure, perhaps libcrypto sha1 is also the same way?
> > Its obvious that you have ran out of sha1_tfms which is why when you
> > actually sleep it helps as other threads would have released theirs.
> >
> > If you dont mind sending ur client code snipped, I could debug..
> > my email id would be [EMAIL PROTECTED]
> >
> > Thanks
> > --Gayathri
> >
> >
> >
> > > Even reducing the thread stack size didn't help.
> > > I observe that the thread creation as such is not a problem. I create
> > > about 1000 threads , delay in each thread the SSL_connect for about 10
> >
> > > sec.
> > > Once the delay expires and each client make connections to the server
> > > the seg fault occurs.
> >
> > You know, looking back at your original trace, it seems I may have
> > jumped
> > to conclusions. It's hard to be sure because I don't know what OpenSSL
> > version you are using, so the line numbers don't tell me anything, but
> > check this
> > out:
> >
> > > #0 SHA1_Init (c=0x0) at sha_locl.h:150
> > > #1 0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
> > > #2 0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230, type=0x4061f620,
> > > impl=0x0) at digest.c:207
> > > #3 0x405ac08e in ssleay_rand_add (buf=0x0, num=0, add=
> > > 2.5863007356866632e-306) at md_rand.c:263
> > > #4 0x405ace6e in RAND_add (buf=0x8a269f8, num=144861688, entropy=0)
> > > at rand_lib.c:151
> >
> > I'm guessing frame #2 is this:
> >
> > return ctx->digest->init(ctx);
> >
> > Which calls this:
> >
> > static int init(EVP_MD_CTX *ctx)
> > { return SHA1_Init(ctx->md_data); }
> >
> > Notice that 'init' was called with a NULL context. But the
> > context
> > cannot have been NULL in frame 2 because if it was ctx->digest would
> > have
> > faulted.
> > So it looks like the stack in frame #2 cannot have lead to the stack in
> > frame #1.
> >
> > This is not a memory exhaustion issue or a failure to check for
> > NULL. It looks like stack corruption. The real puzzle is why stack
> > corruption would only occur with a large number of threads.
> >
> > I'm thinking perhaps there's some concurrency issue with
> > ssleay_rand_add, but I've been over it twice and I don't see any issue.
> > The md context would be unique for each thread, so it should be safe.
> >
> > Maybe someone will read this and it will resonate with something
> > they know?
> > If you can, please tell us what version of OpenSSL this was. This will
> > allow people to understand the line numbers better and make sure they're
> >
> > not looking at code that has whatever bit you already fixed.
> >
> > DS
> >
> >
> > __
Re: Segmentation fault in application creating too many threads.
David,
The OpenSSL version that I use is openssl-0.9.8e. Your guess about methods
being called is right. It appears to be stack corruption.
Gayathri,
I don't suspect the gdb. I checked the CTX status in HASH_INIT (SHA_CTX *c)
under stress , 'c' was indeed NULL and the application immediately dumped.
Regards,
Prabhu. S
On 10/18/07, Gayathri S <[EMAIL PROTECTED]> wrote:
>
>
> The stack trace showing a null sha1 transform kindof caught my attention
> here, I wouldnt go by the the GDB call trace coz its obviously a memory
> leak and the gdb stack could have been corrupted, many a times I see 0x0
> in the frames but when you actually try to print the ctx address it would
> be valid. CTX is definitely valid here,
>
> prabhu, earlier I was assuming you are using the linux sha1 in the kernel
> which is a loadable module, and I realise your just using plain openssl
> from userspace and linking with libcrypto. Linux sha1 has a limitation on
> the sha1_tfm structure, perhaps libcrypto sha1 is also the same way?
> Its obvious that you have ran out of sha1_tfms which is why when you
> actually sleep it helps as other threads would have released theirs.
>
> If you dont mind sending ur client code snipped, I could debug..
> my email id would be [EMAIL PROTECTED]
>
> Thanks
> --Gayathri
>
>
>
> > Even reducing the thread stack size didn't help.
> > I observe that the thread creation as such is not a problem. I create
> > about 1000 threads , delay in each thread the SSL_connect for about 10
> > sec.
> > Once the delay expires and each client make connections to the server
> > the seg fault occurs.
>
> You know, looking back at your original trace, it seems I may have jumped
> to conclusions. It's hard to be sure because I don't know what OpenSSL
> version you are using, so the line numbers don't tell me anything, but
> check this
> out:
>
> > #0 SHA1_Init (c=0x0) at sha_locl.h:150
> > #1 0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
> > #2 0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230, type=0x4061f620,
> > impl=0x0) at digest.c:207
> > #3 0x405ac08e in ssleay_rand_add (buf=0x0, num=0, add=
> > 2.5863007356866632e-306) at md_rand.c:263
> > #4 0x405ace6e in RAND_add (buf=0x8a269f8, num=144861688, entropy=0)
> > at rand_lib.c:151
>
> I'm guessing frame #2 is this:
>
> return ctx->digest->init(ctx);
>
> Which calls this:
>
> static int init(EVP_MD_CTX *ctx)
> { return SHA1_Init(ctx->md_data); }
>
> Notice that 'init' was called with a NULL context. But the context
> cannot have been NULL in frame 2 because if it was ctx->digest would have
> faulted.
> So it looks like the stack in frame #2 cannot have lead to the stack in
> frame #1.
>
> This is not a memory exhaustion issue or a failure to check for
> NULL. It looks like stack corruption. The real puzzle is why stack
> corruption would only occur with a large number of threads.
>
> I'm thinking perhaps there's some concurrency issue with
> ssleay_rand_add, but I've been over it twice and I don't see any issue.
> The md context would be unique for each thread, so it should be safe.
>
> Maybe someone will read this and it will resonate with something
> they know?
> If you can, please tell us what version of OpenSSL this was. This will
> allow people to understand the line numbers better and make sure they're
> not looking at code that has whatever bit you already fixed.
>
> DS
>
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
>
>
>
>
> This email message (including any attachments) is for the sole use of the
> intended recipient(s)
> and may contain confidential, proprietary and privileged information. Any
> unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient,
> please immediately notify the sender by reply email and destroy all copies
> of the original message.
> Thank you.
>
> Intoto Inc.
>
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager [EMAIL PROTECTED]
>
