[openssl-dev] [openssl.org #1596] Re: wrong AKI in cert
we updated the doc in commit 724a1d2 for master. closing ticket. -- Rich Salz, OpenSSL dev team; rs...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=1596 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #1596] wrong AKI in cert
When a certificate is re-signed via "x509 -signkey" while keeping the
existing extensions (i.e. without "-clrext"), the (unwritten) expectation
is that that all that's being changed is the validity dates, and the
previous certificate content remains unchanged. Yes, the issuer is updated
to match the subject if they are not already the same, and the key is replaced
with the new key if different, but otherwise the certificate remains the same.
This is useful for extending the dates of existing self-signed certificates with
as little change as possible.
What this means in practice is that if something other than just the dates
is changing, one really should use "-clrext" and specify the new desired
extensions.
For example ("bash" inline file syntax):
$ openssl x509 -clrext \
-in old-cert.pem -out new-cert.pem -signkey key.pem \
-extfile <(printf "%s\n%s\n" \
"subjectKeyIdentifier = hash" \
"authorityKeyIdentifier = keyid:always"
)
In such cases one of course also needs to specify any other
desired extensions.
Now it may be argued that a more complicated strategy is possible,
in which:
* It is determined whether the original certificate is self-signed
* If so whether the new key is the original signer
and if either condition fails then, while retaining all other extensions
the subject key identifier and authority key identifier extensions are
dropped and regenerated as specified in the extant configuration.
Logic of that complexity is not in place, and it is not entirely clear
that its absence is a bug in the code, rather than a matter of incomplete
documentation of the limitations of this feature.
My take is that this is best addressed at the documentation level, but if
someone is really keen to try to make the code automatically perform the
right extension surgery, a pull request on Github might be the way to go.
--
Viktor.
-
http://rt.openssl.org/Ticket/Display.html?id=1596
Please log in as guest with password guest if prompted
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #1596] wrong AKI in cert
When a certificate is re-signed via "x509 -signkey" while keeping the
existing extensions (i.e. without "-clrext"), the (unwritten) expectation
is that that all that's being changed is the validity dates, and the
previous certificate content remains unchanged. Yes, the issuer is updated
to match the subject if they are not already the same, and the key is replaced
with the new key if different, but otherwise the certificate remains the same.
This is useful for extending the dates of existing self-signed certificates with
as little change as possible.
What this means in practice is that if something other than just the dates
is changing, one really should use "-clrext" and specify the new desired
extensions.
For example ("bash" inline file syntax):
$ openssl x509 -clrext \
-in old-cert.pem -out new-cert.pem -signkey key.pem \
-extfile <(printf "%s\n%s\n" \
"subjectKeyIdentifier = hash" \
"authorityKeyIdentifier = keyid:always"
)
In such cases one of course also needs to specify any other
desired extensions.
Now it may be argued that a more complicated strategy is possible,
in which:
* It is determined whether the original certificate is self-signed
* If so whether the new key is the original signer
and if either condition fails then, while retaining all other extensions
the subject key identifier and authority key identifier extensions are
dropped and regenerated as specified in the extant configuration.
Logic of that complexity is not in place, and it is not entirely clear
that its absence is a bug in the code, rather than a matter of incomplete
documentation of the limitations of this feature.
My take is that this is best addressed at the documentation level, but if
someone is really keen to try to make the code automatically perform the
right extension surgery, a pull request on Github might be the way to go.
--
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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]
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: 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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[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: 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 Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
