Re: Intermediate CA extension problems.
On Tue, May 16, 2006, Phil Dibowitz wrote: OpenSSL folks, I'm having an issue when making an intermediate CA. As I understand the specs (and please, correct me if I'm wrong), a root (i.e. self-signed) CA can be a v1 certificate, but intermediate CAs must: (a) be v3 (b) have SubjectKeyIdentifier (c) have AuthorityKeyIdentifier (d) have BasicKeyConstraints Is there some reason why you want the root CA to be V1? It is better if it is V3 too. Depends on the spec you read as to whether those are mandatory. In some specs SKID/AKID is recommended but not mandatory. In fact it is AKID that is causing the problem: see below. BasicConstraints (not BasicKeyConstraints) is mandatory though because that indicates the intermediate certificte is a valid CA. Based on that I have a CA that is self-signed with only crlDistributionPoint in it. I'm trying to create an intermediate CA with the above extensions in it and I'm having a problem. I have this in my config: Well if you have an extension then it can't be a v1 certificate. [ v3_ca ] basicConstraints = CA:TRUE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always But when I run: openssl ca -config openssl.cnf -extensions v3_ca -infiles \ certreqs/sub_ca.csr I get: Using configuration from openssl.cnf Check that the request matches the signature Signature ok ERROR: adding extensions in section usr_cert 32587:error:2207707B:X509 V3 routines:V2I_AUTHORITY_KEYID:unable to get issuer keyid:v3_akey.c:151: 32587:error:2206B080:X509 V3 routines:X509V3_EXT_conf:error in extension:v3_conf.c:92:name=authorityKeyIdentifier, value=keyid:always I have a similar setup using a non-openssl solution, thus I'm fairly sure what I want to do is possible, I'm just missing something. Any help would be greatly appreciated. Your problem is that you are telling OpenSSL to include the AKID extension by copying the SKID from the issuing CA. That CA doesn't have an SKID extension so it gives the error. Either remove that extension from the config file or include SKID in the root CA. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Root CA key bit length too small - How do I change this?
This is probably a real noob question but I've no idea where to start looking. I've inherited an openssl based CA. The ROOT CA certificate is 512 bits long. RSA Public Key: (512 bit) Modulus (512 bit): The is the best way to change this? I thought maybe renewal might be the best route but maybe there is a better way. Thanks in advance! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Root CA key bit length too small - How do I change this?
Hello, This is probably a real noob question but I've no idea where to start looking. I've inherited an openssl based CA. The ROOT CA certificate is 512 bits long. RSA Public Key: (512 bit) Modulus (512 bit): The is the best way to change this? I thought maybe renewal might be the best route but maybe there is a better way. You must generate new private key (longer) for CA and self certify. Next you should publish your new CA certificate. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
how can I get cipher suite name by its number? ssl3_get_cipher(unsigned int u)?
Hi folks,
What I want to do is to get the name of the cipher suite server is trying to
use when I receive a server hello.
From server hello's header (SSL version 3.0), I can read out the cipher
suite number, which is, for example 0x0004, and my Ethereal (Version
0.10.13) shows it is TLS_RSA_WITH_RC4_128_MD5 (0x0004). In
/openssl/ssl/s3_lib.c, I found out that /* Cipher 04 */ is
SSL3_TXT_RSA_RC4_128_MD5. Is this a correct mapping? If it is, which API I
can use to get this name?
I tried ssl3_get_cipher(unsigned int u), it returns a different name. For
0x0004, it returns /* Cipher 36 */ TLS1_TXT_DH_DSS_WITH_AES_256_SHA (
DH-DSS-AES256-SHA). The function is like this:
SSL_CIPHER *ssl3_get_cipher(unsigned int u)
{
if (u SSL3_NUM_CIPHERS)
return((ssl3_ciphers[SSL3_NUM_CIPHERS-1-u]));
else
return(NULL);
}
What does the line return((ssl3_ciphers[SSL3_NUM_CIPHERS-1-u])) mean? Why
not just return((ssl3_ciphers[u])) ?
Which one is a correct mapping? Ethereal's Cipher 04 or ssl3_get_cipher()'s
Cipher 36?
Thanks,
Rick
_
Dont just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RC5 in openssl FIPS version (versin 7j) is disabled?
Hi, I am new to the openssl. I just compiled openssl FIPS version and I found out that other crypto functions are OK, but I couldn't call those RC5 crypto function. Is this due to RC5 disabled in FIPS version or RC5 is not FIPS approved? I highly appreciate for any helps. Shicai Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.
Question on serial numbers
In some cases I see serial numbers as octet strings, i.e.: Serial Number: ef:e1:73:da:b3:6a:cf:ad:6b:18:dd:58:7f:6b:49:fe And other cases as an integer, i.e.: Serial Number: 2 (0x2) In openssl's case, self-signed certs use an octet-string (though this seems to not be true in all versions), while all certs signed by the CA seem to use an incrimenting serial number. I work with both openssl and the RSA Keon solution. The laster seems to use octet strings everywhere. What is the difference between these two types of serial numbers? Does one deprecate the other? I didn't see anything in RFC 2459 that addressed this. Thanks, -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Root CA key bit length too small - How do I change this?
You must generate new private key (longer) for CA and self certify. Next you should publish your new CA certificate. As a transition aide, you might want to have your old root also sign the new CA key. /r$ -- SOA Appliances Application Integration Middleware __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question on serial numbers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phil Dibowitz schrieb: Hello Phil, In some cases I see serial numbers as octet strings, i.e.: Serial Number: ef:e1:73:da:b3:6a:cf:ad:6b:18:dd:58:7f:6b:49:fe And other cases as an integer, i.e.: Serial Number: 2 (0x2) The only difference is the size of the number. The moment processors (and C libraries) support 128 bit sized integers you will see both serial numbers printed in decimal... It is only a representation in the output functions. In the real data both are represented as an ASN1 integer, one with 1 byte length, the other with 16 byte length... bye Goetz - -- DMCA: The greed of the few outweighs the freedom of the many -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFEa3xw2iGqZUF3qPYRAjN+AJitHOE0SdplOxApuBUe5vRXxVcsAJ9R7yKH eH4MgUtjQPYXVdM8ZlmgSw== =Uzrl -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question on serial numbers
Goetz Babin-Ebell wrote: Phil Dibowitz schrieb: Hello Phil, In some cases I see serial numbers as octet strings, i.e.: Serial Number: ef:e1:73:da:b3:6a:cf:ad:6b:18:dd:58:7f:6b:49:fe And other cases as an integer, i.e.: Serial Number: 2 (0x2) The only difference is the size of the number. The moment processors (and C libraries) support 128 bit sized integers you will see both serial numbers printed in decimal... It is only a representation in the output functions. In the real data both are represented as an ASN1 integer, one with 1 byte length, the other with 16 byte length... Thanks for the quick reply. Hmm. Then why is it when I create a self-signed CA with openssl I get the former displayed, but when when I then sign a cert with that CA, I get the latter? I don't understand why it is using different byte lengths? -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: RC5 in openssl FIPS version (versin 7j) is disabled?
Hello, Hi, I am new to the openssl. I just compiled openssl FIPS version and I found out that other crypto functions are OK, but I couldn't call those RC5 crypto function. Is this due to RC5 disabled in FIPS version or RC5 is not FIPS approved? I highly appreciate for any helps. Look at http://csrc.nist.gov/cryptval/140-1/140sp/140sp642.pdf Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question on serial numbers
On Wed, May 17, 2006, Phil Dibowitz wrote: Thanks for the quick reply. Hmm. Then why is it when I create a self-signed CA with openssl I get the former displayed, but when when I then sign a cert with that CA, I get the latter? I don't understand why it is using different byte lengths? Depends how the CA is set up. Some cookbook guides from various sources manually set up the OpenSSL serial number file to a small number. The standard OpenSSL tools such as CA.pl use a 64 bit random number for the serial number file. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question on serial numbers
Dr. Stephen Henson wrote: On Wed, May 17, 2006, Phil Dibowitz wrote: Thanks for the quick reply. Hmm. Then why is it when I create a self-signed CA with openssl I get the former displayed, but when when I then sign a cert with that CA, I get the latter? I don't understand why it is using different byte lengths? Depends how the CA is set up. Some cookbook guides from various sources manually set up the OpenSSL serial number file to a small number. The standard OpenSSL tools such as CA.pl use a 64 bit random number for the serial number file. Ah. OK. CA.pl -newca takes a random 64-bit number for the serial number of the CA, and then auto-incriments that for all of the certs it signs. Why random? Why not start at 64-bits of 0s? Is there some benefit here? Thanks. -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Question on serial numbers
On Wed, May 17, 2006, Phil Dibowitz wrote: CA.pl -newca takes a random 64-bit number for the serial number of the CA, and then auto-incriments that for all of the certs it signs. Why random? Why not start at 64-bits of 0s? Is there some benefit here? The serial number is an integer. 64 bits of 0s is 0 which is an illegal serial number. The reason for the random nature is so that OpenSSL by default makes it very unlikely to duplicate issuer names and serial numbers, which is a standard violation and can cause peculiar hard to trace errors in common web browsers. That can be very confusing for beginners. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Changing existing certificates from 512 bits to 2048 bits
I know this is a noob question but I have inherited an existing CA based on openssl. I need to change some existing certificates from 512 bit to 2048 bit. I have the private keys and was wondering if the proper approach was to renew the certificate and modify them there? Or is this not possible? Possible but through another mechanisms? thanks again in advance! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question on serial numbers
Dr. Stephen Henson wrote: On Wed, May 17, 2006, Phil Dibowitz wrote: CA.pl -newca takes a random 64-bit number for the serial number of the CA, and then auto-incriments that for all of the certs it signs. Why random? Why not start at 64-bits of 0s? Is there some benefit here? The serial number is an integer. 64 bits of 0s is 0 which is an illegal serial number. OK, fine, 63 bits of 0's and a 1. =P The reason for the random nature is so that OpenSSL by default makes it very unlikely to duplicate issuer names and serial numbers, which is a standard violation and can cause peculiar hard to trace errors in common web browsers. That can be very confusing for beginners. Wait - just to make sure I understand this... the concern is there might be another CA with the same DN out there, and thus we don't want to start with the same serial numbers as them? Thanks, -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Intermediate CA extension problems.
Dr. Stephen Henson wrote: Your problem is that you are telling OpenSSL to include the AKID extension by copying the SKID from the issuing CA. That CA doesn't have an SKID extension so it gives the error. Either remove that extension from the config file or include SKID in the root CA. So as I mentioned previously, I saw a proprietary solution doing this (generating an AKID keyID without a parent SKID), even though I realized it made no sense. So I called them on it. I asked how they were getting a keyID for AKID when the parent CA had no SKID. They informed me they're calculating a hash of the public key of the parent public key for the AKID... in other words - they're generating a SKID for the parent even though it doesn't have one. Intuitively, this kinda seems wrong to me, but reading the RFC it seems to comply. AKID keyId just needs to uniquely identify the parent public key. I'm curious what your thoughts on this are. Is this a reasonable thing to do? Are there problems with this? In the case where I have this, I plan to re-sign the parent to have SKID, but I'll be in this configuration for a bit before I can do that. Is this AKID bad in any way? Thanks. -- Phil Dibowitz P: 310-360-2330 C: 213-923-5115 Unix Admin, Ticketmaster.com signature.asc Description: OpenPGP digital signature
Re: Changing existing certificates from 512 bits to 2048 bits
I know this is a noob question but I have inherited an existing CA based on openssl. I need to change some existing certificates from 512 bit to 2048 bit. I have the private keys and was wondering if the proper approach was to renew the certificate and modify them there? Or is this not possible? Possible but through another mechanisms? Dear Ray: Your question is unclear. I assume that you are referring to RSA keys with 512 bit and 2048 bit modulus, correct? Even then, your question is needs additional clarification. Do the existing certificates issued by your CA for each entity have: 1) a 512 bit RSA public key that corresponds to that entity's 512 bit RSA private key 2) a digital signature that was generated by the CA's 512 bit RSA private key when signing the certificate In the case of (1), each entity needs to generate a brand new RSA private key with a 2048 bit RSA modulus, and then issue a certificate requested (which need to be validated) before the CA can issue the replacement certificates. In the case of (2), if you have a copy of the original certificate requests, you can simply re-sign them with your new 2048 bit RSA signing key for your CA. Or if you don't, you can use openssl and other tools to extract the data from any issued certificate (RSA public key, X509 subject, X509v3 extensions, etc.) and then re-issue brand new certificates from that data, which you then sign with your new 2048 bit RSA signing key for your CA. Note that for (2) you will need to generate a brand new CA (root) self-signed certificate that contains the corresponding 2048 bit RSA public key of the CA signing key. Also that new CA certificate should also have a different subject to distinguish it from the old CA root certificate. Alicia. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Changing existing certificates from 512 bits to 2048 bits
Alicia, Thank you for getting back to me I need to take the Root CA certificate/private key and change the modulus from 512 bit to 2048 bit. I assume that I have to make a new Root CA Certificate request and then sign it with the old one? The problem that I have is newer devices are not allowing me to insert our internal CA root as a trust root CA. The error message says the root CA is 512bits and must be 2048 bits before it can be accepted. --- Alicia da Conceicao [EMAIL PROTECTED] wrote: I know this is a noob question but I have inherited an existing CA based on openssl. I need to change some existing certificates from 512 bit to 2048 bit. I have the private keys and was wondering if the proper approach was to renew the certificate and modify them there? Or is this not possible? Possible but through another mechanisms? Dear Ray: Your question is unclear. I assume that you are referring to RSA keys with 512 bit and 2048 bit modulus, correct? Even then, your question is needs additional clarification. Do the existing certificates issued by your CA for each entity have: 1) a 512 bit RSA public key that corresponds to that entity's 512 bit RSA private key 2) a digital signature that was generated by the CA's 512 bit RSA private key when signing the certificate In the case of (1), each entity needs to generate a brand new RSA private key with a 2048 bit RSA modulus, and then issue a certificate requested (which need to be validated) before the CA can issue the replacement certificates. In the case of (2), if you have a copy of the original certificate requests, you can simply re-sign them with your new 2048 bit RSA signing key for your CA. Or if you don't, you can use openssl and other tools to extract the data from any issued certificate (RSA public key, X509 subject, X509v3 extensions, etc.) and then re-issue brand new certificates from that data, which you then sign with your new 2048 bit RSA signing key for your CA. Note that for (2) you will need to generate a brand new CA (root) self-signed certificate that contains the corresponding 2048 bit RSA public key of the CA signing key. Also that new CA certificate should also have a different subject to distinguish it from the old CA root certificate. Alicia. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Question on serial numbers
On Wed, May 17, 2006, Phil Dibowitz wrote: Dr. Stephen Henson wrote: The reason for the random nature is so that OpenSSL by default makes it very unlikely to duplicate issuer names and serial numbers, which is a standard violation and can cause peculiar hard to trace errors in common web browsers. That can be very confusing for beginners. Wait - just to make sure I understand this... the concern is there might be another CA with the same DN out there, and thus we don't want to start with the same serial numbers as them? No a newbie would create a CA, install it in a browser (or several browsers) issue some certificates etc. They would then decide they didn't like the expiry date or something else associated with it and then create a second CA entering exactly the same details as before. The two would look identical and certificates issued by the two CA could get duplicate serial numbers all over the place. So the default is to do something safe. If someone knows what they are doing they can use different serial numbers and low values if they wish. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Intermediate CA extension problems.
On Wed, May 17, 2006, Phil Dibowitz wrote: Dr. Stephen Henson wrote: Your problem is that you are telling OpenSSL to include the AKID extension by copying the SKID from the issuing CA. That CA doesn't have an SKID extension so it gives the error. Either remove that extension from the config file or include SKID in the root CA. So as I mentioned previously, I saw a proprietary solution doing this (generating an AKID keyID without a parent SKID), even though I realized it made no sense. So I called them on it. I asked how they were getting a keyID for AKID when the parent CA had no SKID. They informed me they're calculating a hash of the public key of the parent public key for the AKID... in other words - they're generating a SKID for the parent even though it doesn't have one. Intuitively, this kinda seems wrong to me, but reading the RFC it seems to comply. AKID keyId just needs to uniquely identify the parent public key. I'm curious what your thoughts on this are. Is this a reasonable thing to do? Are there problems with this? In the case where I have this, I plan to re-sign the parent to have SKID, but I'll be in this configuration for a bit before I can do that. Is this AKID bad in any way? Well AKID is supposed to be a hint to the authority certificate by matching its SKID. If the authority doesn't have an SKID then its a bit misleading. That wont matter to OpenSSL but other software might decide because the authority doesn't have a matching SKID then it isn't the real signer. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Changing existing certificates from 512 bits to 2048 bits
Thank you for getting back to me I need to take the Root CA certificate/private key and change the modulus from 512 bit to 2048 bit. I assume that I have to make a new Root CA Certificate request and then sign it with the old one? The problem that I have is newer devices are not allowing me to insert our internal CA root as a trust root CA. The error message says the root CA is 512bits and must be 2048 bits before it can be accepted. Dear Ray: You cannot change the RSA key in the root CA certificate from 512 bit to 2048 bits. There is no way to convert a 512 bit RSA key to a 2048 bit key, since the bit size of a RSA key refers to THE HIGH BIT OF THE MODULUS number in the RSA key. You need a brand new RSA key. You need to proceed with the following steps: Step-1) generate a brand new RSA private key with a 2048 bit modulus Step-2) generate a new self-signed root CA certificate the contains the RSA public key from Step-1 and a new X509 subject that is different from the old CA certificate, and is signed with the RSA private key from Step-1 Please note that special care in obtaining random data from multiple sources is needed for Step-1 in order to obtain a secure RSA private key for your CA. OpenSSL has a number of command line options that can be used for Step-1 Step-2. You should find lots of examples on how to do this if you use a search engine (Google). Alicia. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
