[openssl.org #470] Build break on FreeBSD 4.2
Thanks for the correction, it's now applied and committed. This ticket is now resolved. [guest - Tue Jan 21 10:50:11 2003]: The commit for PR: 462 broke build on FreeBSD 4.2, looks like a missing zero or in the #if conditional. -- Richard Levitte __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with signing X509 certificate.
- Original Message -
From: Dr. Stephen Henson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 23, 2003 2:03 AM
Subject: Re: Problem with signing X509 certificate.
On Wed, Jan 22, 2003, Jaco Kroon wrote:
Hallo all
I have a little problem atm where I have to sign certificates. I have
both
the private key, and the ca certificate loaded as cacert and cakey
respectively. Here is the part of the code where I suspect
things break.
/*
* Variables to be used:
* X509 *cacert; // contains CA certificate.
* EVP_PKEY *cakey; // contains CA private key.
*/
X509 *usrcert = X509_new();
if(!usrcert)
{
log_ssl_errors(X509_new);
return ERROR_NULL;
}
if(!X509_set_version(usrcert,USRCERTVERSION))
{
log_ssl_errors(X509_set_version);
return ERROR_SSL;
}
if(!X509_set_issuer_name(usrcert,X509_get_subject_name(cacert)))
{
log_ssl_errors(X509_set_issuer_name/X509_get_subject_name);
return ERROR_SSL;
}
X509_gmtime_adj(X509_get_notBefore(usrcert),0);
X509_gmtime_adj(X509_get_notAfter(usrcert),(long)60*60*24*TRIALPERIOD);
X509_NAME *subject = X509_NAME_new();
if(!subject)
{
log_ssl_errors(X509_NAME_new);
return ERROR_NULL;
}
if(
!X509_NAME_add_entry_by_NID(subject,NID_pkcs9_emailAddress,MBSTRING_ASC,(uns
igned char*)email,-1,-1,0) ||
!X509_NAME_add_entry_by_NID(subject,NID_commonName,MBSTRING_ASC,(unsigned
char*)uname,-1,-1,0)
)
{
log_ssl_errors(X509_NAME_add_entry_by_NID);
return ERROR_SSL;
}
if(!X509_set_subject_name(usrcert,subject))
{
log_ssl_errors(X509_set_subject_name);
return ERROR_SSL;
}
X509_NAME_free(subject);
if(!X509_set_pubkey(usrcert,pkey))
{
log_ssl_errors(X509_set_pubkey);
return ERROR_SSL;
}
EVP_MD *dgst = USR_DGST();
res = X509_sign(usrcert,cakey,dgst);
/*
* res now equals 128 - the size of the private rsa key.
*/
I then go ahead and dump the certificate using X509_print and get
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 0 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=ZA, ST=Gauteng, L=Pretoria, O=InterExcel,
OU=BackupServer,
[EMAIL PROTECTED]
Validity
Not Before: Jan 22 19:20:46 2003 GMT
Not After : Feb 21 19:20:46 2003 GMT
Subject: [EMAIL PROTECTED], CN=6feffc9edd8be3e8
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b9:d5:be:8b:1e:f2:9e:6c:4b:88:5a:84:23:c5:
ec:3e:be:7c:97:1d:e4:c1:f8:c4:45:b5:a6:1e:45:
b9:57:d2:84:36:21:ec:53:35:94:65:18:c9:f8:f5:
ef:da:10:c1:25:14:04:fa:14:77:83:a7:8b:79:ac:
d2:c7:51:f2:6f:8e:83:19:ba:20:8d:ed:96:24:fd:
ad:e9:9c:68:78:92:76:64:c0:b9:54:08:2c:5c:6a:
d0:70:15:75:4c:57:b6:9e:f9:68:b1:44:8e:2a:16:
2e:90:85:73:63:30:43:21:28:f2:46:5d:f7:40:d5:
8a:a5:72:a2:00:0d:f9:7c:d7
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
4c:7b:eb:10:3b:70:7f:d6:96:67:96:2d:55:e6:ce:ab:48:ee:
cc:28:dc:81:9e:2a:b1:80:ac:e5:bf:84:e6:71:b7:56:dd:39:
41:2b:1d:fb:dc:8e:16:85:2a:f0:f7:96:6f:b1:c9:69:38:bc:
46:2e:13:cc:28:5e:95:72:81:81:f7:83:97:80:98:96:35:73:
c7:4e:3b:48:b9:99:60:ae:c8:8f:4f:57:74:73:fb:09:0c:19:
c5:00:37:71:40:1f:cb:2c:3e:11:c5:c8:88:a5:53:f7:d6:61:
e2:f6:76:e7:3b:d8:bb:35:9d:24:21:55:bd:fe:09:81:ee:6b:
70:bc
Which is what I want. Except that when I perform the command openssl
verify -CAfile cacert.pem gencert.pem I get the output:
error 7 at 0 depth lookup:certificate signature failure
And my own program gives more detail:
rsa routines::RSA_verify failed with error code 0x4077068 (bad
signature).
asn1 encoding routines::ASN1_verify failed with error code 0xd079006
(bad
get asn1 object call).
Certificate failed.
I output the X509 certificate using PEM_write_X509(stdout,usrcert) which
I
then pipe into a file.
One problem is probably that you aren't setting the certificate serial
number.
You will get the default of zero which will clash with the CA certificate
serial number. The issuer_name and serial number combination should be
unique.
I don't think this is it. I managed to set up a certificate with excactly
the same parameters using the openssl utitility, including a serial number
of 0. It verified ok. Could it be that I'm not setting it explicitly? Say
I have a string containing a hex number,
[openssl.org #463] PATCH: AIX shared libraries
The originally reported issue is addressed and the ticket is being resolved. Temporary workaround for emerged issue with aix64-cc shared build is documented in PROBLEMS. A. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with signing X509 certificate.
Jaco Kroon wrote: I don't think this is it. I managed to set up a certificate with excactly the same parameters using the openssl utitility, including a serial number of 0. It verified ok. Could it be that I'm not setting it explicitly? Say I have a string containing a hex number, how would I go about converting this to a BN I can use for setting the serial number? You can use the BN_hex2bn() and BN_to_ASN1_INTEGER functions to set the serial number. Also, something else that *might* influence things is that the pkey struct is initialized from a private key using code similar to: RSA *usrrsa; // then proceed to convert the received ASN1 data to an RSA structure. EVP_PKEY *pkey = EVP_PKEY_new(); EVP_PKEY_assign_RSA(pkey,usrrsa); then I don't use pkey again until where I assign it to the certificate. If somehow the private key becomes part of the signature but only the public key ends up in the certificate this will explain it as the hashes at the X509_sign() signs the content of the X509 structure = the private part of the client key doesn't matter. time of signing and at the time of verification will differ, which will explain why I can directly after signing verify and it will verify ok, but after writing out and then verifying it gives a bad signature. If the signing code is written with great care or the X509_set_pubkey only extracts the public key, this should not be a problem. How would I go about getting only the public key? Is it possible to show us both certificates ? Which version of OpenSSL are you using ? OS ? Regards, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #460] Ticket Resolved
I have compiled and installed it through removing -lrevolv,anyways thanks a lot. From: Andy Polyakov via RT [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [openssl.org #460] Ticket Resolved Date: Thu, 23 Jan 2003 10:34:56 +0100 (MET) According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. _ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with signing X509 certificate.
On Thu, 23 Jan 2003 10:59:31 +0100, Nils Larsch [EMAIL PROTECTED] wrote : --- SNIP --- Is it possible to show us both certificates ? Which version of OpenSSL are you using ? OS ? k, first all the os and version info, currently using Debian Linux 3.0 (aka woody - is up to date with all the security updates), the openssl library is version 0.9.6 (according to the official version 0.9.6c but that would miss quite a few security updates ...). But it seems that is the case: $ openssl version OpenSSL 0.9.6c 21 dec 2001 k, I'll look into forcing the use of the newest 0.9.6 version, h? k, first I generate the private key using the command openssl genrsa -out key.pem 1024: -BEGIN RSA PRIVATE KEY- MIICXQIBAAKBgQDzDyooSB3fPsBPoE/Wf38uxDVepvUKSDf8KaQnwYABe3/f3AXB yauL9A2dPsOaLFCJJ13RklDaEal2/qwfp8lNYxYeNPHu4XTUeiHKbmHXYHhIUwRb ZLEppYDyCbzbFGVy1AQOU/btMryHl29+w/jkEZJy/z/TAcdtqVBrwfLORwIDAQAB AoGAT5yV+F+2uRq6rtoZjG5yYAUQXhJdjKKfA88333W30cR72/0bPaAqukqT8v9N 3j/JmUL1reE47lR+p2U/R5cTjcwJuPF8ONUghxLleAE4lbqKEuHxvTT4BJGSRZDh ROYKXbZcAr2iFOibXvYqlzL7mr6UxdS2n1V76P3fajZQZOECQQD9x2XFktoSoRU7 PpEnQX8N4oyxhnVhn8v/3L7hkOkhu4e4P7StXO65PsdBEAJ0CofFCLGQgg5K5AP5 LlOcjLJvAkEA9S+/0I2Wl7arYlMgAryP6E3f7s++Yss5Ov2VFAHNRbM/Ue/8Us0B nWJ4W8rrzM8SBczAAfLKRUSaTOGrgUStqQJBALaaJwyGogsNhO1gE6mfYwBmpr2F 9igMhwjPmTlMv7LZ8MoObL7hQ5RfK5gRIPLGMPMBUmKcchRJBOLjBp56TlkCQBAQ jtrVTBaoq1YH6EMFo9AuugtlpS3H7voEf24OKCr28aEmvjuWnxJ2zzgEdaq3rpCe t73o8IPVWN7MsnYHz/ECQQCY21CMnXNgPq7U64OKG3RuEm5Vx2OLckgp1KECigkl b22fuSFnYhmol/Ggj/mr1o42UA98O1omDv9S1oPRVBKb -END RSA PRIVATE KEY- Here is the certificates, as generated using the openssl program (The correct one): Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=ZA, ST=Gauteng, L=Pretoria, O=InterExcel, OU=BackupServer, [EMAIL PROTECTED] Validity Not Before: Jan 23 11:16:17 2003 GMT Not After : Feb 22 11:16:17 2003 GMT Subject: [EMAIL PROTECTED] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:f3:0f:2a:28:48:1d:df:3e:c0:4f:a0:4f:d6:7f: 7f:2e:c4:35:5e:a6:f5:0a:48:37:fc:29:a4:27:c1: 80:01:7b:7f:df:dc:05:c1:c9:ab:8b:f4:0d:9d:3e: c3:9a:2c:50:89:27:5d:d1:92:50:da:11:a9:76:fe: ac:1f:a7:c9:4d:63:16:1e:34:f1:ee:e1:74:d4:7a: 21:ca:6e:61:d7:60:78:48:53:04:5b:64:b1:29:a5: 80:f2:09:bc:db:14:65:72:d4:04:0e:53:f6:ed:32: bc:87:97:6f:7e:c3:f8:e4:11:92:72:ff:3f:d3:01: c7:6d:a9:50:6b:c1:f2:ce:47 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 2a:e3:34:83:db:b7:89:0a:de:d4:76:c4:60:dc:1c:89:fa:95: 11:4b:ce:31:85:28:88:c9:2b:77:c0:23:68:37:51:f3:93:f2: 8a:c4:b4:71:84:18:5c:bb:00:65:7f:60:b7:16:8c:3d:cd:9f: a3:9e:88:52:2a:5d:03:e8:03:84:a5:89:3a:28:97:ab:53:f7: ba:36:5e:80:f1:58:4e:f2:c4:05:51:4b:73:56:08:3d:d7:cb: 8f:aa:b8:f9:51:ca:c6:3d:08:83:53:42:38:2b:bc:6f:8a:d2: 63:14:02:8a:c2:e3:88:27:2a:b5:cb:60:68:5e:59:cf:43:12: 6c:9d -BEGIN CERTIFICATE- MIICUTCCAboCAQAwDQYJKoZIhvcNAQEFBQAwgZ8xCzAJBgNVBAYTAlpBMRAwDgYD VQQIEwdHYXV0ZW5nMREwDwYDVQQHEwhQcmV0b3JpYTETMBEGA1UEChMKSW50ZXJF eGNlbDEVMBMGA1UECxMMQmFja3VwU2VydmVyMREwDwYDVQQDEwhDbGllbnRDQTEs MCoGCSqGSIb3DQEJARYdYmFja3Vwc2VydmVyQGludGVyZXhjZWwuY28uemEwHhcN MDMwMTIzMTExNjE3WhcNMDMwMjIyMTExNjE3WjBCMRkwFwYDVQQDExBlNzUxODE0 YTNhOWQ0ODJjMSUwIwYJKoZIhvcNAQkBFhZqYWNvQHdlYmZvdW50YWluLmNvLnph MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDzDyooSB3fPsBPoE/Wf38uxDVe pvUKSDf8KaQnwYABe3/f3AXByauL9A2dPsOaLFCJJ13RklDaEal2/qwfp8lNYxYe NPHu4XTUeiHKbmHXYHhIUwRbZLEppYDyCbzbFGVy1AQOU/btMryHl29+w/jkEZJy /z/TAcdtqVBrwfLORwIDAQABMA0GCSqGSIb3DQEBBQUAA4GBACrjNIPbt4kK3tR2 xGDcHIn6lRFLzjGFKIjJK3fAI2g3UfOT8orEtHGEGFy7AGV/YLcWjD3Nn6OeiFIq XQPoA4SliTool6tT97o2XoDxWE7yxAVRS3NWCD3Xy4+quPlRysY9CINTQjgrvG+K 0mMUAorC44gnKrXLYGheWc9DEmyd -END CERTIFICATE- The commands used to generate this was (the start date and end date is based on what is generated by my program): openssl req -config ./openssl.conf -key key.pem -new -out request.pem openssl ca -config ./openssl.conf -name clientCA -in request.pem -startdate 030123111617Z -enddate 030222111617Z -md sha1 -out signed.pem -outdir . - batch afaik you need to edit the serial file to read 00 :). And the certificate generated by my program (The one that fails): Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=ZA, ST=Gauteng, L=Pretoria, O=InterExcel, OU=BackupServer, [EMAIL PROTECTED] Validity Not Before: Jan 23 11:16:17 2003 GMT Not After : Feb 22 11:16:17 2003 GMT
Re: Problem with signing X509 certificate.
Jaco Kroon wrote: I believe that is it, waiting for your reply. I'll try a version upgrade on OpenSSL and let you know anyhow - but somehow I don't think it's going to help :). Hi Jaco, here is the 'openssl asn1parse ...' output of the certificate created by your program: 0:d=0 hl=4 l= 598 cons: SEQUENCE 4:d=1 hl=4 l= 447 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim:INTEGER :00 13:d=2 hl=2 l= 1 prim: INTEGER :00 That's wrong (at least I think so). The default version (v1 == 0x0) shouldn't be encoded in the DER encoding (see RFC 3280 etc.) If you look at 'asn1parse' output of the other certificate (created with openssl): 0:d=0 hl=4 l= 593 cons: SEQUENCE 4:d=1 hl=4 l= 442 cons: SEQUENCE 8:d=2 hl=2 l= 1 prim: INTEGER :00 11:d=2 hl=2 l= 13 cons: SEQUENCE 13:d=3 hl=2 l= 9 prim:OBJECT:sha1WithRSAEncryption you see that the version number (0x0) is omitted. I'm not really familiar with the 0.9.6 OpenSSL ASN1 code but could you try two things: a) set the version to 02 (== X509v3 certificate) and b) don't set the version at all. Regards, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Problem with signing X509 certificate.
here is the 'openssl asn1parse ...' output of the certificate created by your program: 0:d=0 hl=4 l= 598 cons: SEQUENCE 4:d=1 hl=4 l= 447 cons: SEQUENCE 8:d=2 hl=2 l= 3 cons: cont [ 0 ] 10:d=3 hl=2 l= 1 prim:INTEGER :00 13:d=2 hl=2 l= 1 prim: INTEGER :00 That's wrong (at least I think so). The default version (v1 == 0x0) shouldn't be encoded in the DER encoding (see RFC 3280 etc.) If you look at 'asn1parse' output of the other certificate (created with openssl): 0:d=0 hl=4 l= 593 cons: SEQUENCE 4:d=1 hl=4 l= 442 cons: SEQUENCE 8:d=2 hl=2 l= 1 prim: INTEGER :00 11:d=2 hl=2 l= 13 cons: SEQUENCE 13:d=3 hl=2 l= 9 prim:OBJECT:sha1WithRSAEncryption you see that the version number (0x0) is omitted. I'm not really familiar with the 0.9.6 OpenSSL ASN1 code but could you try two things: a) set the version to 02 (== X509v3 certificate) and b) don't set the version at all. Neither of those helped and a version upgrade won't be needed. I managed to fix the problem. Closely related to what the first reply implied that a default serial number of 0 is not good, is the fact that the serial number has to be set explicitly. I suspect that what happened is something like this: X509_new initializes the X509 structure, setting most fields (pointers mostly?) to NULL. This will indicate no serial number. I then go and add all the other fields, serial number still NULL. X509_sign then hashes all the fields except serial number, and signs it. i2d_X509 then goes and adds the serial number (Am I correct in saying that PEM_write_X509 calls i2d_X509?), changing the certificate, and indirectly the hash value, making the signature invalid. It would be nice if this can be confirmed. If this is not the case, why is it needed to explicitly set the serial number? Thanks a million for your help. Jaco Kroon www.webfountain.co.za [EMAIL PROTECTED] +27 72 215 2548 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #472] Exception when running openssl req comma nd after Jan 18th
Stephen, Thanks for the reply. We were kind of hit over the head with this, as it had been working fine for quite a while with no problems and suddenly blew up on us. Both the openssl application and the 2 dll's are the official 0.9.7 release. I searched the machine and these are the only versions on the machine. I have tried this on several machines also, just to eliminate any concern that it is my machine. I also tried a few of the recent snapshot stable builds and they exhibit the same problem. I have not backed up and tried a 0.9.6 build yet. The exact command that I ran was: openssl req -config openssl.cnf -new -x509 -days 12784 -sha1 -newkey rsa:1024 -keyout CA\private\cakey.pem -out CA\certs\cacert.pem -passin file:CA\pass\ca_pp -passout file:CA\pass\caout_pp Where ca_pp and caout_pp are both simple text files with a single line containing a passphrase. Here is the output from my DOS windows: C:\uap8245\tools\caopenssl req -config openssl.cnf -new -x509 -days 12784 -sha1 -newkey rsa:1024 -keyout CA\private\cakey.pem -out CA\certs\cacert.pem -passin file:CA\pass\ca_pp -passout file:CA\pass\caout_pp Using configuration from openssl.cnf Loading 'screen' into random state - done Generating a 1024 bit RSA private key ...++ ...++ writing new private key to 'CA\private\cakey.pem' - You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. - Country Name (2 letter code) [US]: State or Province Name (full name) [Washington]: Locality Name (eg, city) [Everett]: Organization Name (eg, company) [Intermec Technologies Corporation]: Organizational Unit Name (eg, section) [Security Engineering]: Common Name (eg, YOUR name) [Intermec Technologies Corporation]: Email Address []: Immediately after receiving all of the input information for the cert, I get the exception. It looks from the nice cryptic windows message that somebody is accessing a null pointer, the windows error message is: openssl.exe - Application Error The instruction at 0x0035bccc referenced memory at 0x. The memory could not be read. Opening a debugger provides the following error message: Unhandled exception in openssl.exe (LIBEAY32.DLL): 0xC005: Access Violation To give more information than you probably want, here are the registers: EAX = EBX = ECX = EDX = 003D0608 ESI = 00933708 EDI = 00933E80 EIP = 0035BCCC ESP = 0012F46C EBP = 009310F8 EFL = 0246 MM0 = MM1 = MM2 = MM3 = MM4 = MM5 = MM6 = MM7 = B400 XMM0 = XMM1 = XMM2 = XMM3 = XMM4 = XMM5 = XMM6 = XMM7 = CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 0038 GS = OV=0 UP=0 EI=1 PL=0 ZR=1 AC=0 PE=1 CY=0 XMM0DL = +0.00E+000 XMM0DH = +0.00E+000 XMM1DL = +0.00E+000 XMM1DH = +0.00E+000 XMM2DL = +0.00E+000 XMM2DH = +0.00E+000 XMM3DL = +0.00E+000 XMM3DH = +0.00E+000 XMM4DL = +0.00E+000 XMM4DH = +0.00E+000 XMM5DL = +0.00E+000 XMM5DH = +0.00E+000 XMM6DL = +0.00E+000 XMM6DH = +0.00E+000 XMM7DL = +0.00E+000 XMM7DH = +0.00E+000 XMM00 = +0.0E+000 XMM01 = +0.0E+000 XMM02 = +0.0E+000 XMM03 = +0.0E+000 XMM10 = +0.0E+000 XMM11 = +0.0E+000 XMM12 = +0.0E+000 XMM13 = +0.0E+000 XMM20 = +0.0E+000 XMM21 = +0.0E+000 XMM22 = +0.0E+000 XMM23 = +0.0E+000 XMM30 = +0.0E+000 XMM31 = +0.0E+000 XMM32 = +0.0E+000 XMM33 = +0.0E+000 XMM40 = +0.0E+000 XMM41 = +0.0E+000 XMM42 = +0.0E+000 XMM43 = +0.0E+000 XMM50 = +0.0E+000 XMM51 = +0.0E+000 XMM52 = +0.0E+000 XMM53 = +0.0E+000 XMM60 = +0.0E+000 XMM61 = +0.0E+000 XMM62 = +0.0E+000 XMM63 = +0.0E+000 XMM70 = +0.0E+000 XMM71 = +0.0E+000 XMM72 = +0.0E+000 XMM73 = +0.0E+000 MXCSR = 1F80 ST0 = +0.0e+ ST1 = +0.0e+ ST2 = +0.0e+ ST3 = +0.0e+ ST4 = +0.0e+ ST5 = +0.0e+ ST6 = +0.0e+ ST7 = +4.5e+0001 CTRL = 027F STAT = TAGS = EIP = 00350C69 CS = 001B DS = 0023 EDO =
certification path validation suite
Hello, I send that message to the openssl-dev list because the same problem is likely to have occurred or to occur in a near future to openssl developpers. I am currently developping an implementation of the certification path validation algorithm described in section 6.1 of RFC 3280. I need some test certificates to check the correctness of my implementation. I have already come accross the test suite from the NIST: http://csrc.nist.gov/pki/testing/x509paths.html These certificates are great, and my software now handles them as specified (rejecting what needs to be rejected, accepting what needs to be accepted), but they do not test all the features I wish to support. Namely, the following are of chief interest to me and I have come accross no publicly available certificate that use them: -- policy qualifiers (CPS URI and user notices) -- policy mappings -- name constraints -- subjectAltName extension -- DSS signing while using the DSS parameters from another certificate So my questions are: 1. Is there any test suite available somewhere, which covers my needs ? 2. I heard the NIST is preparing an advanced test suite which might be of some help; is there any info about when this test suite will be ready ? 3. If there is no reference test suite available, should it be assumed that there exists no tested, and, therefore with high probability no correct, implementation of the certification path validation algorithm which handles the policy mappings and name constraints ? Thanks for any information, --Thomas Pornin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certification path validation suite
Dear Thomas, The consortium that I am currently in have some test suites for policy mapping, or more specifically cross certification situation. But I am not sure how much our test suites are suitable for your needs. Now we evaluate the test suites using several implementations. There will be published around March 2003. For more information, please contact me directly. -Kiyoshi Kiyoshi Watanabe Hello, I send that message to the openssl-dev list because the same problem is likely to have occurred or to occur in a near future to openssl developpers. I am currently developping an implementation of the certification path validation algorithm described in section 6.1 of RFC 3280. I need some test certificates to check the correctness of my implementation. I have already come accross the test suite from the NIST: http://csrc.nist.gov/pki/testing/x509paths.html These certificates are great, and my software now handles them as specified (rejecting what needs to be rejected, accepting what needs to be accepted), but they do not test all the features I wish to support. Namely, the following are of chief interest to me and I have come accross no publicly available certificate that use them: -- policy qualifiers (CPS URI and user notices) -- policy mappings -- name constraints -- subjectAltName extension -- DSS signing while using the DSS parameters from another certificate So my questions are: 1. Is there any test suite available somewhere, which covers my needs ? 2. I heard the NIST is preparing an advanced test suite which might be of some help; is there any info about when this test suite will be ready ? 3. If there is no reference test suite available, should it be assumed that there exists no tested, and, therefore with high probability no correct, implementation of the certification path validation algorithm which handles the policy mappings and name constraints ? Thanks for any information, --Thomas Pornin __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #472] Exception when running openssl req command after Jan 18th
[[EMAIL PROTECTED] - Thu Jan 23 15:33:56 2003]: Stephen, Thanks for the reply. We were kind of hit over the head with this, as it had been working fine for quite a while with no problems and suddenly blew up on us. Both the openssl application and the 2 dll's are the official 0.9.7 release. I searched the machine and these are the only versions on the machine. I have tried this on several machines also, just to eliminate any concern that it is my machine. I also tried a few of the recent snapshot stable builds and they exhibit the same problem. I have not backed up and tried a 0.9.6 build yet. The exact command that I ran was: openssl req -config openssl.cnf -new -x509 -days 12784 -sha1 -newkey rsa:1024 -keyout CA\private\cakey.pem -out CA\certs\cacert.pem -passin file:CA\pass\ca_pp -passout file:CA\pass\caout_pp [stuff deleted] Regarding compiler, I used Visual C++ 6.0 with service pack 6. nmake version 6.00.8168.0. Whats SP6? Never seen that, I've got SP5 though... I am running Windows XP, SP1 with all the updates. The cause is that rather large value you use for -days and the behaviour of the Windows gmtime function. If the value of time_t passed to gmtime under Windows is a date before the 1970 epoch it returns NULL instead of the static pointer to the tm structure. This isn't handled properly by the openssl code and causes a crash. The reason the time appears before the epoch is that time_t is a signed long on Win32 and if you add a big enough value it wraps around and ends up negative. So if you give a large enough -days value this will happen. The workaround is to use a smaller -days value. We should fix the openssl utility to check for errors in the appropriate functions, which would at least stop the crash and give some meaningful error message. Ideally I suppose we should have alternative routines which can handle larger dates. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certification path validation suite
In message [EMAIL PROTECTED] on Thu, 23 Jan 2003 18:16:31 +0100, Thomas Pornin [EMAIL PROTECTED] said: pornin 2. I heard the NIST is preparing an advanced test suite which porninmight be of some help; is there any info about when this pornintest suite will be ready ? I believe that the following message is relevant in this case: http://www.imc.org/ietf-pkix/mail-archive/msg05517.html pornin 3. If there is no reference test suite available, should it be porninassumed that there exists no tested, and, therefore with porninhigh probability no correct, implementation of the pornincertification path validation algorithm which handles the porninpolicy mappings and name constraints ? Uhmm, I'm quite sure the US Government uses those extensively, as well as others, so I'm sure tests exist. However, if they are free for anyone to use remains to be seen... -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #472] Exception when running openssl req comma nd after Jan 18th
Sorry, SP5 not SP6. I figured it had to do with a time value overflowing a variable size. I'll crank down the days value temporarily to workaround it. Thanks for the help. Felt silly sending off the report instead of just digging in and fixing it, but staying ahead of layoffs here has kept me more than busy. -Jason -Original Message- From: Stephen Henson via RT [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 12:46 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [openssl.org #472] Exception when running openssl req command after Jan 18th [[EMAIL PROTECTED] - Thu Jan 23 15:33:56 2003]: Stephen, Thanks for the reply. We were kind of hit over the head with this, as it had been working fine for quite a while with no problems and suddenly blew up on us. Both the openssl application and the 2 dll's are the official 0.9.7 release. I searched the machine and these are the only versions on the machine. I have tried this on several machines also, just to eliminate any concern that it is my machine. I also tried a few of the recent snapshot stable builds and they exhibit the same problem. I have not backed up and tried a 0.9.6 build yet. The exact command that I ran was: openssl req -config openssl.cnf -new -x509 -days 12784 -sha1 -newkey rsa:1024 -keyout CA\private\cakey.pem -out CA\certs\cacert.pem -passin file:CA\pass\ca_pp -passout file:CA\pass\caout_pp [stuff deleted] Regarding compiler, I used Visual C++ 6.0 with service pack 6. nmake version 6.00.8168.0. Whats SP6? Never seen that, I've got SP5 though... I am running Windows XP, SP1 with all the updates. The cause is that rather large value you use for -days and the behaviour of the Windows gmtime function. If the value of time_t passed to gmtime under Windows is a date before the 1970 epoch it returns NULL instead of the static pointer to the tm structure. This isn't handled properly by the openssl code and causes a crash. The reason the time appears before the epoch is that time_t is a signed long on Win32 and if you add a big enough value it wraps around and ends up negative. So if you give a large enough -days value this will happen. The workaround is to use a smaller -days value. We should fix the openssl utility to check for errors in the appropriate functions, which would at least stop the crash and give some meaningful error message. Ideally I suppose we should have alternative routines which can handle larger dates. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #475] [Fwd: patch to 0.9.7 -performacne]
Maybe openssl-bugs is the right forum? This really isn't a bug, but a
performance improvement.
-david
-Forwarded Message-
From: David Brumley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: patch to 0.9.7 -performacne
Date: 23 Jan 2003 11:53:09 -0800
Hi,
I wrote awhile back about a patch to 0.9.7 in rsa_eay.c, but never heard
back. Is this the wrong forum?
The patch is to rsa_eay.c (attached), which adds cacheing of the
montgomery context for n (in addition to p and q). This patch improves
efficiency...normally the verify at the end of CRT does not use a cached
context. In 0.9.7 right now, R^{-1} (Ri) for n must be recomputed on
every decryption, an expensive operation.
-david
--- rsa_eay.c.orig 2003-01-20 19:16:46.0 -0800
+++ rsa_eay.c 2003-01-20 19:17:54.0 -0800
@@ -533,6 +533,31 @@
if (bn_mont_ctx)
BN_MONT_CTX_free(bn_mont_ctx);
}
+
+ if (rsa-_method_mod_n == NULL)
+ {
+ BN_MONT_CTX* bn_mont_ctx;
+ if ((bn_mont_ctx=BN_MONT_CTX_new()) == NULL)
+ goto err;
+ if (!BN_MONT_CTX_set(bn_mont_ctx,rsa-n,ctx))
+ {
+ BN_MONT_CTX_free(bn_mont_ctx);
+ goto err;
+ }
+ if (rsa-_method_mod_n == NULL) /* other thread may have
+finished first */
+ {
+ CRYPTO_w_lock(CRYPTO_LOCK_RSA);
+ if (rsa-_method_mod_n == NULL)
+ {
+ rsa-_method_mod_n = bn_mont_ctx;
+ bn_mont_ctx = NULL;
+ }
+ CRYPTO_w_unlock(CRYPTO_LOCK_RSA);
+ }
+ if (bn_mont_ctx)
+ BN_MONT_CTX_free(bn_mont_ctx);
+ }
+
}
if (!BN_mod(r1,I,rsa-q,ctx)) goto err;
@@ -565,7 +590,7 @@
if (rsa-e rsa-n)
{
- if (!rsa-meth-bn_mod_exp(vrfy,r0,rsa-e,rsa-n,ctx,NULL)) goto err;
+ if
+(!rsa-meth-bn_mod_exp(vrfy,r0,rsa-e,rsa-n,ctx,rsa-_method_mod_n)) goto err;
/* If 'I' was greater than (or equal to) rsa-n, the operation
* will be equivalent to using 'I mod n'. However, the result of
* the verify will *always* be less than 'n' so we don't check
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: [openssl.org #436] openssl-0.9.7 inconsistency error
I can't get it. So lets drop and and try again later Joseph A Amaturo President Amatech Solutions, Inc. AT Concepts, Inc. (P) 845-988-9876 (C) 845-590-7914 (F) 845-988-9899 www.amatechsolutions.com Microsoft Certified Partner -Original Message- From: Lutz Jaenicke via RT [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 23, 2003 2:27 AM To: Joseph A. Amaturo Cc: [EMAIL PROTECTED] Subject: [openssl.org #436] openssl-0.9.7 inconsistency error [jaenicke - Wed Jan 15 12:30:08 2003]: Any new information? No response for another week. I therefore close the ticket. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #444] Win32 crash in PEM_read_X509
[[EMAIL PROTECTED] - Sun Jan 19 08:28:56 2003]: Did you build a debug version of OpenSSL to link against for the debug build? This isn't handled automatically and you need to change it so it picks up and uses the debug libraries. Nope. that would explain it. criss-crossing MS multi-threaded libs is always a problem. I was using my debug build (the release was probably set up somewhat incorrectly since I had not touched it yet), so I was using a mismatched pair of libs. thanks for the clarification. OK, since Andy has now committed the VC++ AES workaround too this ticket is resolved. Steve. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: certification path validation suite
On Thu, Jan 23, 2003, Thomas Pornin wrote: Hello, 3. If there is no reference test suite available, should it be assumed that there exists no tested, and, therefore with high probability no correct, implementation of the certification path validation algorithm which handles the policy mappings and name constraints ? There was some debate about how some options in name constraints should be interpreted in the PKIX mailing lists not long ago. This suggests that correct may be subject to interpretation :-) I've never seen a certificate with either name or policy constraints in the field or indeed privately. Examples would be useful to check out any future OpenSSL support for them. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #472] Exception when running openssl req command after Jan 18th
[[EMAIL PROTECTED] - Thu Jan 23 20:34:01 2003]: Sorry, SP5 not SP6. I figured it had to do with a time value overflowing a variable size. I'll crank down the days value temporarily to workaround it. I've committed a fix now. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
