Re: [openssl.org #1596] Re: wrong AKI in cert
Since x509 -signkey is supposed to create self-signed certificates, it's supposed to set AKID == SKID. It also has to set the SKID if it plugs in a new public key which I dont think it does either. I think the same problem is in openssl x509 ... -CA ... which also can create a new cert from an existing cert and preserves the extensions by just copying them. P.S. thanks for the rt action on this one. I think I am still stumped though as there is no workaround for my certs since they all have the SKID AKID in the extensions. Actually it would work for me except for the validation failure in the second command as the self-signed cert is just a temporary and my final cert is the same subject/issuer as the original so it will match the extensions again. If the validation is using the AKID then it will never work. Thanks, Simon McMahon Kyle Hamilton via RT [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 25/10/2007 07:48 PM Please respond to openssl-dev@openssl.org To cc openssl-dev@openssl.org Subject [openssl.org #1596] Re: wrong AKI in cert I think you're right, there's an issue with AKID/SKID in x509 - signkey. (I'm sending this on to [EMAIL PROTECTED], to open a ticket for it.) Repeat the mantra: Only the Certifier has AKID == SKID. Certificates have AKID == CA's SKID. Now, forget the mantra, cuz the only exception is self-signed certificates. (which is all a CA's certificate really is, if it's a trust anchor.) Since x509 -signkey is supposed to create self-signed certificates, it's supposed to set AKID == SKID. Now. I'm on OpenSSL 0.9.8e 23 Feb 2007, and I just did the following sequence: mkdir phase1 mkdir phase2 CA.pl -newca (generate demoCA/cacert.pem and demoCA/private/ cakey.pem) (SKID A8:2E, AKID A8:2E) CA.pl -newcert (generate newcert.pem and newkey.pem) (SKID D8:75, AKID D8:75) mv *.pem phase1 CA.pl -newreq (generate newreq.pem and newkey.pem) CA.pl -sign (generate newcert.pem) (SKID FB:9E, AKID A8:2E) mv *.pem phase2 cd phase2 openssl x509 -in newcert.pem -out intermediary.pem -signkey newkey.pem intermediary.pem reports SKID FB:9E, AKID A8:2E. It should set AKID = SKID for -signkey, and so the AKID should be FB:9E. -Kyle H On Oct 24, 2007, at 11:01 PM, Simon McMahon wrote: Hi, cross ref on support list: Re: refresh validity dates on a certificate. While trying to refresh validity on certs I noticed that openssl x509 ... -signkey filename modifies the issuer name. It also preserves the extensions but appears to copy them verbatum. If there is a X509v3 Authority Key Identifier in there then it may not match the issuers key in the resulting cert. If it is producing a self-signed cert then surely the AKI and the SKI should be the same. Other openssl commands appear to try to verify this resulting cert and fail. I think if openssl is going to set the issuer and resign the cert then it should also update the AKI if it is present in the extensions. If it sets the subject public key then it should also update the X509v3 Subject Key Identifier extension if present. I was using 9.8b. This is a cert where subject = issuer but ski != aki. In this case it should be aki = ski. Certificate: Data: Version: 3 (0x2) Serial Number: 15 (0xf) Signature Algorithm: sha1WithRSAEncryption Issuer: C=AU, ST=Queensland, O=IBM, L=Gold Coast, OU=GSKit, CN=sslcln Validity Not Before: Oct 25 04:00:23 2007 GMT Not After : Aug 14 04:00:23 2010 GMT Subject: C=AU, ST=Queensland, O=IBM, L=Gold Coast, OU=GSKit, CN=sslcln Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a9:b1:99:5a:c2:d5:83:a6:6d:ea:d1:1f:f2:8c: bf:43:6c:a2:09:07:f8:14:2f:f7:07:e4:cb:57:d9: 53:2e:55:68:86:c8:4d:8f:d2:3a:5a:81:ca:65:b0: 83:0a:97:6e:5a:15:f5:df:65:8f:e0:27:e3:dc:d1: 84:3a:ac:a2:d8:a9:9e:69:e1:5f:1d:88:10:72:85: 7e:ea:a4:db:79:43:0b:63:6b:4f:e0:8f:ee:09:9a: 66:14:bb:b1:48:2d:17:0f:da:c0:f9:12:8e:a2:98: a5:61:86:85:14:10:30:c2:28:00:fd:0c:cb:ca:71: 9f:34:e0:8e:f5:25:f0:73:93 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 8B:44:9A:12:AE:E1:D0:7F:6F:0C:60:87:1E:A6:8A:D8:9C:3D:57:57 X509v3 Authority Key Identifier: keyid:89:9E:C2:C4:E6:87:4E:C2:DC:9E:DE:A7:D5:BE:64:F6:BF:2C:1E:2C X509v3 Subject Alternative Name: EMPTY Signature Algorithm: sha1WithRSAEncryption 3a:15:9e:2d:0f:01:aa:b7:a2:86:b8:09:47:6b:00:7f:16:3a
Re: [openssl.org #1596] Re: wrong AKI in cert
Since x509 -signkey is supposed to create self-signed certificates, it's supposed to set AKID == SKID. It also has to set the SKID if it plugs in a new public key which I dont think it does either. I think the same problem is in openssl x509 ... -CA ... which also can create a new cert from an existing cert and preserves the extensions by just copying them. P.S. thanks for the rt action on this one. I think I am still stumped though as there is no workaround for my certs since they all have the SKID AKID in the extensions. Actually it would work for me except for the validation failure in the second command as the self-signed cert is just a temporary and my final cert is the same subject/issuer as the original so it will match the extensions again. If the validation is using the AKID then it will never work. Thanks, Simon McMahon Kyle Hamilton via RT [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 25/10/2007 07:48 PM Please respond to openssl-dev@openssl.org To cc openssl-dev@openssl.org Subject [openssl.org #1596] Re: wrong AKI in cert I think you're right, there's an issue with AKID/SKID in x509 - signkey. (I'm sending this on to [EMAIL PROTECTED], to open a ticket for it.) Repeat the mantra: Only the Certifier has AKID == SKID. Certificates have AKID == CA's SKID. Now, forget the mantra, cuz the only exception is self-signed certificates. (which is all a CA's certificate really is, if it's a trust anchor.) Since x509 -signkey is supposed to create self-signed certificates, it's supposed to set AKID == SKID. Now. I'm on OpenSSL 0.9.8e 23 Feb 2007, and I just did the following sequence: mkdir phase1 mkdir phase2 CA.pl -newca (generate demoCA/cacert.pem and demoCA/private/ cakey.pem) (SKID A8:2E, AKID A8:2E) CA.pl -newcert (generate newcert.pem and newkey.pem) (SKID D8:75, AKID D8:75) mv *.pem phase1 CA.pl -newreq (generate newreq.pem and newkey.pem) CA.pl -sign (generate newcert.pem) (SKID FB:9E, AKID A8:2E) mv *.pem phase2 cd phase2 openssl x509 -in newcert.pem -out intermediary.pem -signkey newkey.pem intermediary.pem reports SKID FB:9E, AKID A8:2E. It should set AKID = SKID for -signkey, and so the AKID should be FB:9E. -Kyle H On Oct 24, 2007, at 11:01 PM, Simon McMahon wrote: Hi, cross ref on support list: Re: refresh validity dates on a certificate. While trying to refresh validity on certs I noticed that openssl x509 ... -signkey filename modifies the issuer name. It also preserves the extensions but appears to copy them verbatum. If there is a X509v3 Authority Key Identifier in there then it may not match the issuers key in the resulting cert. If it is producing a self-signed cert then surely the AKI and the SKI should be the same. Other openssl commands appear to try to verify this resulting cert and fail. I think if openssl is going to set the issuer and resign the cert then it should also update the AKI if it is present in the extensions. If it sets the subject public key then it should also update the X509v3 Subject Key Identifier extension if present. I was using 9.8b. This is a cert where subject = issuer but ski != aki. In this case it should be aki = ski. Certificate: Data: Version: 3 (0x2) Serial Number: 15 (0xf) Signature Algorithm: sha1WithRSAEncryption Issuer: C=AU, ST=Queensland, O=IBM, L=Gold Coast, OU=GSKit, CN=sslcln Validity Not Before: Oct 25 04:00:23 2007 GMT Not After : Aug 14 04:00:23 2010 GMT Subject: C=AU, ST=Queensland, O=IBM, L=Gold Coast, OU=GSKit, CN=sslcln Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a9:b1:99:5a:c2:d5:83:a6:6d:ea:d1:1f:f2:8c: bf:43:6c:a2:09:07:f8:14:2f:f7:07:e4:cb:57:d9: 53:2e:55:68:86:c8:4d:8f:d2:3a:5a:81:ca:65:b0: 83:0a:97:6e:5a:15:f5:df:65:8f:e0:27:e3:dc:d1: 84:3a:ac:a2:d8:a9:9e:69:e1:5f:1d:88:10:72:85: 7e:ea:a4:db:79:43:0b:63:6b:4f:e0:8f:ee:09:9a: 66:14:bb:b1:48:2d:17:0f:da:c0:f9:12:8e:a2:98: a5:61:86:85:14:10:30:c2:28:00:fd:0c:cb:ca:71: 9f:34:e0:8e:f5:25:f0:73:93 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 8B:44:9A:12:AE:E1:D0:7F:6F:0C:60:87:1E:A6:8A:D8:9C:3D:57:57 X509v3 Authority Key Identifier: keyid:89:9E:C2:C4:E6:87:4E:C2:DC:9E:DE:A7:D5:BE:64:F6:BF:2C:1E:2C X509v3 Subject Alternative Name: EMPTY Signature Algorithm: sha1WithRSAEncryption 3a:15:9e:2d:0f:01:aa:b7:a2:86:b8:09:47:6b:00:7f:16:3a
wrong AKI in cert
Hi, cross ref on support list: Re: refresh validity dates on a certificate. While trying to refresh validity on certs I noticed that openssl x509 ... -signkey filename modifies the issuer name. It also preserves the extensions but appears to copy them verbatum. If there is a X509v3 Authority Key Identifier in there then it may not match the issuers key in the resulting cert. If it is producing a self-signed cert then surely the AKI and the SKI should be the same. Other openssl commands appear to try to verify this resulting cert and fail. I think if openssl is going to set the issuer and resign the cert then it should also update the AKI if it is present in the extensions. If it sets the subject public key then it should also update the X509v3 Subject Key Identifier extension if present. I was using 9.8b. This is a cert where subject = issuer but ski != aki. In this case it should be aki = ski. Certificate: Data: Version: 3 (0x2) Serial Number: 15 (0xf) Signature Algorithm: sha1WithRSAEncryption Issuer: C=AU, ST=Queensland, O=IBM, L=Gold Coast, OU=GSKit, CN=sslcln Validity Not Before: Oct 25 04:00:23 2007 GMT Not After : Aug 14 04:00:23 2010 GMT Subject: C=AU, ST=Queensland, O=IBM, L=Gold Coast, OU=GSKit, CN=sslcln Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:a9:b1:99:5a:c2:d5:83:a6:6d:ea:d1:1f:f2:8c: bf:43:6c:a2:09:07:f8:14:2f:f7:07:e4:cb:57:d9: 53:2e:55:68:86:c8:4d:8f:d2:3a:5a:81:ca:65:b0: 83:0a:97:6e:5a:15:f5:df:65:8f:e0:27:e3:dc:d1: 84:3a:ac:a2:d8:a9:9e:69:e1:5f:1d:88:10:72:85: 7e:ea:a4:db:79:43:0b:63:6b:4f:e0:8f:ee:09:9a: 66:14:bb:b1:48:2d:17:0f:da:c0:f9:12:8e:a2:98: a5:61:86:85:14:10:30:c2:28:00:fd:0c:cb:ca:71: 9f:34:e0:8e:f5:25:f0:73:93 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 8B:44:9A:12:AE:E1:D0:7F:6F:0C:60:87:1E:A6:8A:D8:9C:3D:57:57 X509v3 Authority Key Identifier: keyid:89:9E:C2:C4:E6:87:4E:C2:DC:9E:DE:A7:D5:BE:64:F6:BF:2C:1E:2C X509v3 Subject Alternative Name: EMPTY Signature Algorithm: sha1WithRSAEncryption 3a:15:9e:2d:0f:01:aa:b7:a2:86:b8:09:47:6b:00:7f:16:3a: 32:46:11:be:06:16:f0:b8:cc:67:6e:8e:fe:32:14:5d:87:1c: ea:da:fa:81:e8:e7:e8:9f:c5:e1:06:4b:cc:2e:de:f7:bc:df: 9e:60:be:94:23:67:b9:76:c9:47:4d:0c:ab:61:a5:eb:5e:3e: d3:50:c5:4b:4c:d3:92:a3:7e:31:03:dd:68:64:6a:e3:53:df: 26:0b:c0:a0:d7:ff:a6:7d:5b:29:6f:50:8a:b7:8e:45:90:c8: 1f:2e:a2:43:14:69:54:32:82:3c:90:b1:70:b2:8e:c1:b7:5d: df:f7 Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1458] garbage-in garbage-out - was OCSP response nonce extension encoding not DER
Looks like OpenSSL has a problem/feature of garbage-in garbage-out. It's a problem because it does not comply with the RFC and a feature because it lets OpenSSL work with broken clients. My OCSP request from some time ago had the encoding error of encoding the default values and it looks like OpenSSL just returns the encoding of the nonce extension that it got rather than re-encoding it as DER. Actually the encoding can be BER but the ... signature SHALL be computed on the hash of the DER encoding ... is clear. This explains why OpenSSL now works for me - because the request (with nonce) from my end is now DER encoded. Regards, Simon McMahon Simon McMahon/Australia/Contr/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/10/2007 12:56 PM Please respond to openssl-users@openssl.org To openssl-users@openssl.org cc Subject OCSP response nonce extension encoding not DER Hi, Just saw some weirdness in OCSP response encodings with a nonce extension. The OCSP response has this for the extensions: A1 1E 30 1C 30 1A 06 09 2B 06 01 05 05 07 30 01 02 01 01 00 --- 04 0A 04 08 A5 10 18 67 E5 A4 8B 2C The sencond last item is the 'false' (00) for the 'critical' field. 'false' is the default value (rfc 3280) so should not appear in a DER encoding. Here is another OCSP response extension and this is how it should be for DER: A1 1B 30 19 30 17 06 09 2B 06 01 05 05 07 30 01 02 04 0A 04 08 D4 4C 29 A8 C6 1A 16 56 The 'false' is not there. Note that afaik both were produced by the same version of OpenSSL but at different times. I haven't been able to reproduce the one containing the 'false' and since I cant reproduce a response like this, and the most recent one I produced was OK I'm not 100% sure what is going on. I only noticed this because my validitator used to accept the first response, now it rejects it. It reencodes the resp to DER, before checking the sig. RFC 2560 says the signature SHALL be computed on the hash of the DER encoding The error I get is a bad signature. The entire ocsp response is attached. Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Bug: ocsp response - signature SHALL be computed on the hash of the DER encoding
Hi, I reported this in the 'user' forum also as 'garbage-in garbage-out' - but not as a bug. Looks like a BER encoded nonce in an OCSP request gets copied back in the response - the critical flag was 'false' which is the default so should not be encoded for DER. The signature appears to be computed over the actual encoding, which can be BER, not the DER encoding as specified in the RFC. Therefore the encodings are all legal but the OpenSSL signatures are not in this case. I've seen this problem before and we always had to re-encode the object in DER before making or checking the signature. I have confirmed that OpenSSL will return a non-BER encoded response to match the request. I haven't confirmed how the OpenSSL signature is computed but I know that my code rejected the OpenSSL responses after I fixed it to do the sig over a correct DER encoding. Attached is a response with the 'false' encoded in it - i.e. a non-DER request - not signed. The response comes back the same. If you send in a correct response, or let OpenSSL generate one then it is correctly DER encoded. Ok, it is a pretty obscure bug and I only found it because I had a much worse bug - encoding defaults when it's supposed to be DER :-). But maybe this effect crops up elsewhere though. Regards, Simon McMahon notder.oreq Description: Binary data test.orsp Description: Binary data
Re: Windows build fail of openssl-SNAP-20061114
Sorry for asking before looking. I found it: Delete IMPLEMENT_ASN1_SET_OF @4194 from libeay32.def. Cheers. Simon McMahon/Australia/Contr/IBM 11/15/2006 03:44 PM To openssl-dev@openssl.org cc Subject Windows build fail of openssl-SNAP-20061114 Hi, Using MSVC++ 6.0 I followed all the instructions in install.w32 including: perl util\mkdef.pl crypto ssl update to get the things not having numbers assigned error to go away. Then: ms\do_ms worked ok. Then: nmake -f ms\ntdll.mak built the .c files but failed on the link: rc /fotmp32dll\libeay32.res /d CRYPTO ms\version32.rc link /nologo /subsystem:console /opt:ref /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\DOCUME~1\simonm\LOCALS~1\Temp\nma02892. LIBEAY32.def : error LNK2001: unresolved external symbol IMPLEMENT_ASN1_SET_OF out32dll\libeay32.lib : fatal error LNK1120: 1 unresolved externals LINK : fatal error LNK1141: failure during build of exports file NMAKE : fatal error U1077: 'link' : return code '0x475' Stop. I went back to openssl-0.9.8d and it built OK for me. Any suggestions? Thanks, Simon McMahon. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[PATCH] Re: Windows build fail of openssl-SNAP-20061114
Thanks Victor,
I got it by editing libeay32.def but the effect is the same.
I also fixed it with the following patch to mkdef.pl
--- util/mkdef.pl 2006-06-10 02:01:14.0 +1000
+++ mkdef.pl2006-11-16 09:42:53.0 +1000
@@ -754,6 +754,8 @@
$def .= int i2d_$1_NDEF(void);;
} elsif
(/^\s*DECLARE_ASN1_SET_OF\s*\(\s*(\w*)\s*\)/) {
next;
+ } elsif
(/^\s*IMPLEMENT_ASN1_SET_OF\s*\(\s*(\w*)\s*\)/) {
+ next;
} elsif
(/^\s*DECLARE_ASN1_PRINT_FUNCTION\s*\(\s*(\w*)\s*\)/) {
$def .= int $1_print_ctx(void);;
next;
This results in this macro being marked as NOEXIST.
Note: its just a copy of the lines above for 'DECLARE_ASN1_SET_OF' which
is also an empty macro so I assume they should be handled the same.
Cheers,
Simon McMahon.
Victor B. Wagner [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/15/2006 05:56 PM
Please respond to
openssl-dev@openssl.org
To
openssl-dev@openssl.org
cc
Subject
Re: Windows build fail of openssl-SNAP-20061114
On 2006.11.15 at 15:47:40 +1000, Simon McMahon wrote:
Hi,
Using MSVC++ 6.0
I followed all the instructions in install.w32 including:
perl util\mkdef.pl crypto ssl update
to get the things not having numbers assigned error to go away. Then:
ms\do_ms
worked ok. Then:
nmake -f ms\ntdll.mak
built the .c files but failed on the link:
rc /fotmp32dll\libeay32.res /d CRYPTO ms\version32.rc
link /nologo /subsystem:console /opt:ref /dll
/out:out32dll\libeay32.dll
/def:ms/LIBEAY32.def @C:\DOCUME~1\simonm\LOCALS~1\Temp\nma02892.
LIBEAY32.def : error LNK2001: unresolved external symbol
IMPLEMENT_ASN1_SET_OF
out32dll\libeay32.lib : fatal error LNK1120: 1 unresolved externals
LINK : fatal error LNK1141: failure during build of exports file
NMAKE : fatal error U1077: 'link' : return code '0x475'
Stop.
I went back to openssl-0.9.8d and it built OK for me.
Any suggestions?
Manually edit libeay.num file after running
mkdef.pl crypto ssl update and just remove line containing
IMPLEMENT_ASN1_SET_OF.
It is not a function, it is a macro, but for some reason I've not found
time to investigate, mkdef consider it a function.
It is not a problem for those who wish just build OpenSSL. It is problem
for people who wish to add new functions and make mkdef.pl see them.
Really, someone who have deep understanding of mkdef.pl work should
check header files, find out what's wrong with IMPLEMENT_ASN1_SET_OF
macro - why mkdef consider it a function, but handles other such macros
(there are lot of them) appropriately, and fix either header or mkdef.pl
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Windows build fail of openssl-SNAP-20061114
Hi, Using MSVC++ 6.0 I followed all the instructions in install.w32 including: perl util\mkdef.pl crypto ssl update to get the things not having numbers assigned error to go away. Then: ms\do_ms worked ok. Then: nmake -f ms\ntdll.mak built the .c files but failed on the link: rc /fotmp32dll\libeay32.res /d CRYPTO ms\version32.rc link /nologo /subsystem:console /opt:ref /dll /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\DOCUME~1\simonm\LOCALS~1\Temp\nma02892. LIBEAY32.def : error LNK2001: unresolved external symbol IMPLEMENT_ASN1_SET_OF out32dll\libeay32.lib : fatal error LNK1120: 1 unresolved externals LINK : fatal error LNK1141: failure during build of exports file NMAKE : fatal error U1077: 'link' : return code '0x475' Stop. I went back to openssl-0.9.8d and it built OK for me. Any suggestions? Thanks, Simon McMahon. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
ocsp responder certificate generation documentation
Hi, There is nothing (that I could find) in the ocsp(1) doc on how to generate OCSP responder certificates with openssl. In the openssl.cnf you need: [ ocsp_cert ] extendedKeyUsage = OCSP Signing then add -extensions ocsp_cert on the openssl ca command to generate the cert. Note the space in the OID name! Using OCSPsigning doesn't work. There is also an unrelated mistake in the doc: OCSP Response verification ... Initially the OCSP responder certificate is located and the signature on the OCSP request checked using the responder certificate's public key. Should be ... and the signature on the OCSP response checked OCSP request checking is something different. Regards, Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: openssl ca - configuration file options - oid_section (0.9.8b)
Hi Steve, Thanks for your reply. I found out what I did wrong. Dr Stephen N. Henson wrote: for details and examples. However the OID is already part of OpenSSL so it doesn't need to be added: it is called OCSPSigning though. It appears to be called OCSP Signing which caused me a bit of a problem since it is most often referred to without the space. Maybe the space could be dropped? Cheers, Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
openssl ca - configuration file options - oid_section (0.9.8b)
Hi, I must have something wrong in the configuration file and there dont seem to be samples to cover additional OIDs. I just want to know how to use the 'oid_section' in the openssl.cnf file correctly. Btw, I am simply adding the OCSPsigning extendedKeyUsage attribute to the cert. I can do that but not using the oid that I defined. I tried adding the following lines to the standard (supplied) openssl.cnf file: [ CA_default ] oid_section = oids [ oids ] OCSPsigning = 1.3.6.1.5.5.7.3.9 [ ocsp_cert ] extendedKeyUsage = OCSPsigning Note: the sections have other stuff in them also - I am just showing the additions. Then running: openssl ca -in csr.pem -out xcert.pem -extensions ocsp_cert gives output: Error Loading extension section ocsp_cert 2920:error:0D06407A:asn1 encoding routines:a2d_ASN1_OBJECT:first num too large:. \crypto\asn1\a_object.c:108: 2920:error:2206706E:X509 V3 routines:V2I_EXTENDED_KEY_USAGE:invalid object ident ifier:.\crypto\x509v3\v3_extku.c:135:section:,name:OCSPsigning,value: 2920:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:.\crypt o\x509v3\v3_conf.c:93:name=extendedKeyUsage, value=OCSPsigning If I switch to: [ ocsp_cert ] extendedKeyUsage = 1.3.6.1.5.5.7.3.9 It works fine giving output: Certificate Details: ... X509v3 extensions: ... X509v3 Extended Key Usage: OCSP Signing How do I get the oid_section to work so I can use those oids that I defined? Regards, Simon McMahon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1132] double pass SMIME
Hi Steve, I found a bug in the earlier submission where the single run (2 pass) produced slightly different encoding than 2 separate passes. The attachment is a fixed /apps/smime.c - its actually less lines changed than the previous one. I'm not sure how to generate just a patch file. The patch is to 0.9.8 again. Regards, Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 [EMAIL PROTECTED] 06/23/05 07:41pm Hi Steve, Richard, OK, the file is attached. The file modified was from openssl-0.9.8-beta6\apps\smime.c It is just a simple hack to make it do a double pass over the file to do both operations in the one call - sorry but I used a goto :-). My user likes it much better this way because they have to call smime ... (or openssl smime ...) from their application and the double call (for sign then encrypt) is high overhead. They always do both sign/encrypt and decrypt/verify. All existing functionality is unchanged. I have tested it for both sign/encrypt and decrypt/verify and it works OK for me. Regards, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 Dr. Stephen Henson [EMAIL PROTECTED] 06/23/05 11:05am On Thu, Jun 23, 2005, Simon McMahon wrote: Hi Steve, OpenSSL is a busy forum so I just thought I would get some directions before posting to the list(s). I have been using OpenSSL's SMIME support and I have added a usability feature for my user that I would like to submit for the general distribution. Is there a process for this? In a nutshell the change is to allow OpenSSL smime ... to do sign/encrypt or decrypt/verify in a single call rather than in 2 calls. It's pretty basic stuff but it has high impact on performance where an application is making callouts (lots of them) to openssl.exe from another program. I modified 9.7g - file /apps/smime.c is the only one effected (about 20 lines of code). Well the best way would be to subit this patch to RT then it wont get lost :-) Its better if additional features patch against the latest development version, in this case 0.9.9-dev though that's currently identical to 0.9.8-stable. 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 *** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *** __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] smime.c Description: Binary data
[openssl.org #1132] double pass SMIME
Hi Steve, I found a bug in the earlier submission where the single run (2 pass) produced slightly different encoding than 2 separate passes. The attachment is a fixed /apps/smime.c - its actually less lines changed than the previous one. I'm not sure how to generate just a patch file. The patch is to 0.9.8 again. Regards, Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 [EMAIL PROTECTED] 06/23/05 07:41pm Hi Steve, Richard, OK, the file is attached. The file modified was from openssl-0.9.8-beta6\apps\smime.c It is just a simple hack to make it do a double pass over the file to do both operations in the one call - sorry but I used a goto :-). My user likes it much better this way because they have to call smime ... (or openssl smime ...) from their application and the double call (for sign then encrypt) is high overhead. They always do both sign/encrypt and decrypt/verify. All existing functionality is unchanged. I have tested it for both sign/encrypt and decrypt/verify and it works OK for me. Regards, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 Dr. Stephen Henson [EMAIL PROTECTED] 06/23/05 11:05am On Thu, Jun 23, 2005, Simon McMahon wrote: Hi Steve, OpenSSL is a busy forum so I just thought I would get some directions before posting to the list(s). I have been using OpenSSL's SMIME support and I have added a usability feature for my user that I would like to submit for the general distribution. Is there a process for this? In a nutshell the change is to allow OpenSSL smime ... to do sign/encrypt or decrypt/verify in a single call rather than in 2 calls. It's pretty basic stuff but it has high impact on performance where an application is making callouts (lots of them) to openssl.exe from another program. I modified 9.7g - file /apps/smime.c is the only one effected (about 20 lines of code). Well the best way would be to subit this patch to RT then it wont get lost :-) Its better if additional features patch against the latest development version, in this case 0.9.9-dev though that's currently identical to 0.9.8-stable. 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 *** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *** __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1132] Re: submission of OpenSSL changes
Hi Steve, Richard, OK, the file is attached. The file modified was from openssl-0.9.8-beta6\apps\smime.c It is just a simple hack to make it do a double pass over the file to do both operations in the one call - sorry but I used a goto :-). My user likes it much better this way because they have to call smime ... (or openssl smime ...) from their application and the double call (for sign then encrypt) is high overhead. They always do both sign/encrypt and decrypt/verify. All existing functionality is unchanged. I have tested it for both sign/encrypt and decrypt/verify and it works OK for me. Regards, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 Dr. Stephen Henson [EMAIL PROTECTED] 06/23/05 11:05am On Thu, Jun 23, 2005, Simon McMahon wrote: Hi Steve, OpenSSL is a busy forum so I just thought I would get some directions before posting to the list(s). I have been using OpenSSL's SMIME support and I have added a usability feature for my user that I would like to submit for the general distribution. Is there a process for this? In a nutshell the change is to allow OpenSSL smime ... to do sign/encrypt or decrypt/verify in a single call rather than in 2 calls. It's pretty basic stuff but it has high impact on performance where an application is making callouts (lots of them) to openssl.exe from another program. I modified 9.7g - file /apps/smime.c is the only one effected (about 20 lines of code). Well the best way would be to subit this patch to RT then it wont get lost :-) Its better if additional features patch against the latest development version, in this case 0.9.9-dev though that's currently identical to 0.9.8-stable. 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 *** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *** __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Apache: Cannot load .../modules/mod_ssl.so into server: (182)
Hi, On startup Apache says: Cannot load /apache/1.3.24/modules/mod_ssl.so into server: (182) I am running Apache as a service and get this error. Can anyone help please? Thanks, Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 *** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *** __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
