openssl req: 100% CPU with too long country name input
Hi!
I'm resending this, seem my initial email (to r...@openssl.org only,
Cc:'ed again) didn't show up, neither here, nor in RT.
My coworker Sebastian discovered a glitch while playing with `pkitool'
of OpenVPN's `easy-rsa'[1]. This was observed with Debian's
libssl-1.0.1g-3: If input for a country name is longer than the
expected two bytes. openssl will spit out an endless stream of
--- 8 === error message =
string is too long, it needs to be less than 2 bytes long
= 8 -
We noticed that there's configury for the country name's length
(countryName_min and countryName_max). Those have some effect, but
there seems to be a hardcoded limit imposed, too. But whatever is
configured as a minimum/maximum length, openssl shouldn't just go to
100% CPU.
This is a working testcase:
--- 8 = testcase.sh =
#!/usr/bin/env bash
CFG=/tmp/openssl-conf-$$.cnf
export PKCS11TOOL=pkcs11-tool
export PKCS11_MODULE_PATH=dummy
export PKCS11_PIN=dummy
export KEY_EXPIRE=3650
export KEY_ORG=Fort-Funston
export KEY_CITY=SanFrancisco
export KEY_SIZE=2048
export KEY_OU=MyOrganizationalUnit
export KEY_EMAIL=me@myhost.mydomain
export KEY_CONFIG=${CFG}
export KEY_NAME=EasyRSA
export KEY_COUNTRY=US-
export KEY_DIR=/tmp
export KEY_CN=Fort-Funston CA
export KEY_PROVINCE=CA
cat ${CFG} 'EOF'
HOME= .
RANDFILE= $ENV::HOME/.rnd
openssl_conf= openssl_init
[ openssl_init ]
oid_section = new_oids
engines = engine_section
[ new_oids ]
[ ca ]
default_ca = CA_default# The default ca section
[ CA_default ]
dir = $ENV::KEY_DIR # Where everything is kept
certs = $dir # Where the issued certs are kept
crl_dir = $dir # Where the issued crl are kept
database= $dir/index.txt# database index file.
new_certs_dir = $dir # default place for new certs.
certificate = $dir/ca.crt # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/ca.key # The private key
RANDFILE= $dir/.rand# private random number file
x509_extensions = usr_cert # The extentions to add to the cert
default_days= 3650 # how long to certify for
default_crl_days= 30# how long before next CRL
default_md = sha256# use public key default MD
preserve= no# keep passed DN ordering
policy = policy_anything
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName= match
organizationalUnitName = optional
commonName = supplied
name= optional
emailAddress= optional
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName= optional
organizationName= optional
organizationalUnitName = optional
commonName = supplied
name= optional
emailAddress= optional
[ req ]
default_bits= $ENV::KEY_SIZE
default_keyfile = privkey.pem
default_md = sha256
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = nombstr
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = $ENV::KEY_COUNTRY
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = $ENV::KEY_PROVINCE
localityName= Locality Name (eg, city)
localityName_default= $ENV::KEY_CITY
0.organizationName = Organization Name (eg, company)
0.organizationName_default = $ENV::KEY_ORG
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, your name or your server\'s
hostname)
commonName_max = 64
name= Name
name_max= 64
emailAddress= Email Address
emailAddress_default= $ENV::KEY_EMAIL
emailAddress_max= 40
organizationalUnitName_default = $ENV::KEY_OU
commonName_default = $ENV::KEY_CN
name_default = $ENV::KEY_NAME
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName= An optional company name
[ usr_cert ]
basicConstraints=CA:FALSE
nsComment = Easy-RSA Generated Certificate
[openssl.org #3347] openssl req: 100% CPU with too long country input
Hi!
My coworker Sebastian discovered a glitch while playing with `pkitool'
of OpenVPN's `easy-rsa'[1]. This was observed with Debian's
libssl-1.0.1g-3: If input for a country name is longer than the
expected two bytes. openssl will spit out an endless stream of
--- 8 === error message =
string is too long, it needs to be less than 2 bytes long
= 8 -
We noticed that there's configury for the country name's length
(countryName_min and countryName_max). Those have some effect, but
there seems to be a hardcoded limit imposed, too. But whatever is
configured as a minimum/maximum length, openssl shouldn't just go to
100% CPU.
This is a working testcase:
--- 8 testcase =
#!/usr/bin/env bash
CFG=/tmp/openssl-conf-$$.cnf
export PKCS11TOOL=pkcs11-tool
export PKCS11_MODULE_PATH=dummy
export PKCS11_PIN=dummy
export KEY_EXPIRE=3650
export KEY_ORG=Fort-Funston
export KEY_CITY=SanFrancisco
export KEY_SIZE=2048
export KEY_OU=MyOrganizationalUnit
export KEY_EMAIL=me@myhost.mydomain
export KEY_CONFIG=${CFG}
export KEY_NAME=EasyRSA
export KEY_COUNTRY=US-
export KEY_DIR=/tmp
export KEY_CN=Fort-Funston CA
export KEY_PROVINCE=CA
cat ${CFG} 'EOF'
HOME= .
RANDFILE= $ENV::HOME/.rnd
openssl_conf= openssl_init
[ openssl_init ]
oid_section = new_oids
engines = engine_section
[ new_oids ]
[ ca ]
default_ca = CA_default# The default ca section
[ CA_default ]
dir = $ENV::KEY_DIR # Where everything is kept
certs = $dir # Where the issued certs are kept
crl_dir = $dir # Where the issued crl are kept
database= $dir/index.txt# database index file.
new_certs_dir = $dir # default place for new certs.
certificate = $dir/ca.crt # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/ca.key # The private key
RANDFILE= $dir/.rand# private random number file
x509_extensions = usr_cert # The extentions to add to the cert
default_days= 3650 # how long to certify for
default_crl_days= 30# how long before next CRL
default_md = sha256# use public key default MD
preserve= no# keep passed DN ordering
policy = policy_anything
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName= match
organizationalUnitName = optional
commonName = supplied
name= optional
emailAddress= optional
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName= optional
organizationName= optional
organizationalUnitName = optional
commonName = supplied
name= optional
emailAddress= optional
[ req ]
default_bits= $ENV::KEY_SIZE
default_keyfile = privkey.pem
default_md = sha256
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
string_mask = nombstr
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = $ENV::KEY_COUNTRY
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = $ENV::KEY_PROVINCE
localityName= Locality Name (eg, city)
localityName_default= $ENV::KEY_CITY
0.organizationName = Organization Name (eg, company)
0.organizationName_default = $ENV::KEY_ORG
organizationalUnitName = Organizational Unit Name (eg, section)
commonName = Common Name (eg, your name or your server\'s
hostname)
commonName_max = 64
name= Name
name_max= 64
emailAddress= Email Address
emailAddress_default= $ENV::KEY_EMAIL
emailAddress_max= 40
organizationalUnitName_default = $ENV::KEY_OU
commonName_default = $ENV::KEY_CN
name_default = $ENV::KEY_NAME
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName= An optional company name
[ usr_cert ]
basicConstraints=CA:FALSE
nsComment = Easy-RSA Generated Certificate
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
extendedKeyUsage=clientAuth
keyUsage = digitalSignature
[
[openssl.org #3349] Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
I posted this test case for function X509_check_akid() on the
openssl-users mailing list, but got no reaction, therefore I'm
submitting it now as a defect for triaging.
Test case:
1) Certificate that has an Authority Key Identifier extension (save as
file testcert.pem):
-BEGIN CERTIFICATE-
MIIBvzCCASigAwIBAgIBAjANBgkqhkiG9w0BAQsFADASMRAwDgYDVQQDDAdUZXN0
IENBMB4XDTE0MDUwMjA5MDI1OFoXDTE0MDYwMTA5MDI1OFowFDESMBAGA1UEAwwJ
VGVzdCBDZXJ0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCwnv66JvZTVaf
Z3tqMo5od80yv9J0rxUMlAPXFiRM3P/JgDjW5NVIt2Ryaqwd7qZFN1f0HpcQAM5m
SJsQpi8ZxbfGB9BIt7SgRuKdj5ntDX1WJ84gl4C8R2t75B8d0WrJBJUYL2XCOEnu
S0RpfxvLZryH8Pr48Wp8NM6gONAjgQIDAQABoyMwITAfBgNVHSMEGDAWgBQLHOwh
WWaA9y49g7bt77DLa5/RKjANBgkqhkiG9w0BAQsFAAOBgQB7Md75mT3aHcR1vyf7
q8t5+x2JzbXxY3bSF1eRreaC65luDGwHrwd8e6vsYQGfOL35Q9lz+6eJRQWFsLkV
LoILyOEJlfJIN2hX7ZOphTsQ4xhgUanBtQBh7a3if4ywF6YMS8XgBwCxXcmrndGm
OZLjSWhsx6spsyLl56iduRWtzQ==
-END CERTIFICATE-
2) Test program that loads the certificate and invokes X509_check_akid()
for the certificate with its own Authority Key Identifier (all error
checks omitted for brevity):
snip ---
/*
* Test program for X509_check_akid()
*
* The program loads a certificate that has the
* X509v3 Authority Key Identifier and invokes X509_check_akid()
* with this authority key identifier and the certificate itself.
*/
#include stdio.h
#include openssl/err.h
#include openssl/bio.h
#include openssl/evp.h
#include openssl/x509.h
#include openssl/x509v3.h
#include openssl/pem.h
int
main()
{
BIO *pem;
const char *file = testcert.pem;
X509 *cert;
int akid_check;
pem = BIO_new(BIO_s_file());
BIO_read_filename(pem, file);
cert = PEM_read_bio_X509_AUX(pem, NULL, NULL, NULL);
X509_check_purpose(cert, -1, -1);
akid_check = X509_check_akid(cert, cert-akid);
printf(X509_check_akid result %d '%s'\n, akid_check,
X509_verify_cert_error_string(akid_check));
return 0;
}
--- snip ---
Actual result:
When compiled and executed with a current OpenSSL build from the
OpenSSL_1_0_2-stable branch the program prints:
X509_check_akid result 0 'ok'
Expected result:
X509_check_akid() should return an error code because the certificate
actually cannot be identified as its own issuer via the X509v3 Authority
Key Identifier extension.
Background:
The test case scenario actually occurs in an application that uses
X509_verify_cert() where certain checks are disabled through a callback
function applied with X509_STORE_set_verify_cb(). A certificate is
incorrectly identified as the CRL issuer certificate through this behavior.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
OpenSSL compilation error
Hi, I am trying to compile fips enabled openssl 0.9.8y for 64 bit Windows. But I am getting following errors. AMIC_ENGINE -D_WINDLL -c .\fips\fips_premain.c fips_premain.c link /nologo /subsystem:console /opt:ref /out:out32dll\fips_premain_dso. exe @C:\Tmp\1\nm3F.tmp Creating library out32dll\fips_premain_dso.lib and object out32dll\fips_prema in_dso.exp bss_fd.obj : error LNK2019: unresolved external symbol OPENSSL_UplinkTable refer enced in function fd_free bss_file.obj : error LNK2001: unresolved external symbol OPENSSL_UplinkTable b_dump.obj : error LNK2001: unresolved external symbol OPENSSL_UplinkTable out32dll\fips_premain_dso.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'C:\Program Files\Microsoft Visual Studio 8\VC\BIN\x 86_amd64\link.EXE' : return code '0x460' Stop. I tried some of methods suggested on net but nothing worked. Please help if some has any idea about these errors. Regards, Alok
Re: [openssl.org #3349] (Proposed PATCH) Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
On Thu, May 08, 2014 at 09:48:43AM +0200, Stephan M?hlstrasser via RT wrote: I posted this test case for function X509_check_akid() on the openssl-users mailing list, but got no reaction, therefore I'm submitting it now as a defect for triaging. Test case: 1) Certificate that has an Authority Key Identifier extension (save as file testcert.pem): [ but no subject key id, so the authority key id should not match itself ] If so, and if the patch below does not break other use-cases, it may fix your issue. diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c index 6c40c7d..7466938 100644 --- a/crypto/x509v3/v3_purp.c +++ b/crypto/x509v3/v3_purp.c @@ -744,8 +744,8 @@ int X509_check_akid(X509 *issuer, AUTHORITY_KEYID *akid) return X509_V_OK; /* Check key ids (if present) */ - if(akid-keyid issuer-skid -ASN1_OCTET_STRING_cmp(akid-keyid, issuer-skid) ) + if(akid-keyid (!issuer-skid || +ASN1_OCTET_STRING_cmp(akid-keyid, issuer-skid)) ) return X509_V_ERR_AKID_SKID_MISMATCH; /* Check serial number */ if(akid-serial -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3349] (Proposed PATCH) Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
Am 08.05.14 15:14, schrieb Viktor Dukhovni: Test case: 1) Certificate that has an Authority Key Identifier extension (save as file testcert.pem): [ but no subject key id, so the authority key id should not match itself ] If so, and if the patch below does not break other use-cases, it may fix your issue. I can confirm that with this patch applied my use case with X509_verify_cert() works as expected (misidentification of signing certificate as CRL issuer no longer occurs). I think that this patch only prevents misidentifications of issuer certificates via authority key identifier, so all legitimate use cases should be unaffected. Thanks for looking into this so quickly! diff --git a/crypto/x509v3/v3_purp.c b/crypto/x509v3/v3_purp.c index 6c40c7d..7466938 100644 --- a/crypto/x509v3/v3_purp.c +++ b/crypto/x509v3/v3_purp.c @@ -744,8 +744,8 @@ int X509_check_akid(X509 *issuer, AUTHORITY_KEYID *akid) return X509_V_OK; /* Check key ids (if present) */ - if(akid-keyid issuer-skid -ASN1_OCTET_STRING_cmp(akid-keyid, issuer-skid) ) + if(akid-keyid (!issuer-skid || +ASN1_OCTET_STRING_cmp(akid-keyid, issuer-skid)) ) return X509_V_ERR_AKID_SKID_MISMATCH; /* Check serial number */ if(akid-serial Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3349] (Proposed PATCH) Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
On Thu, May 08, 2014, Viktor Dukhovni wrote: On Thu, May 08, 2014 at 09:48:43AM +0200, Stephan M?hlstrasser via RT wrote: I posted this test case for function X509_check_akid() on the openssl-users mailing list, but got no reaction, therefore I'm submitting it now as a defect for triaging. Test case: 1) Certificate that has an Authority Key Identifier extension (save as file testcert.pem): [ but no subject key id, so the authority key id should not match itself ] Well technically AKID should only be used as a hint (various PKIX list discissions have confirmed this). In that sense OpenSSL is already too strict: if AKID completely mismatches it will decide that the candidate certificate cannot be an issuer. What it should do is check multiple candidate certificates and give preference (all things being equal) to a certificate with an AKID match to one that does not match AKID. It should not however completely exclude a certificate if AKID does not match. That change for all cases is non-trivial however and would introduce binary compatibility issues if introduced in a stable branch. As such that patch might break *something*. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3349] (Proposed PATCH) Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
Am 08.05.14 16:15, schrieb Dr. Stephen Henson: Well technically AKID should only be used as a hint (various PKIX list discissions have confirmed this). In that sense OpenSSL is already too strict: if AKID completely mismatches it will decide that the candidate certificate cannot be an issuer. I don't understand the usefulness of the AKID then. If it's only a hint and can't even be used to exclude certain certificates as issuers, what is it good for? Assuming that the behavior of X509_check_akid() is correct, maybe the usage of it in crl_akid_check() in x509_vfy.c is not correct then because it relies on the answer of X509_check_akid()? As the AKID is only a hint, shouldn't crl_akid_check() verify by other means that the candidate is actually the issuer? -- Stephan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3349] (Proposed PATCH) Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
On Thu, May 08, 2014, Stephan Mhlstrasser wrote: Am 08.05.14 16:15, schrieb Dr. Stephen Henson: Well technically AKID should only be used as a hint (various PKIX list discissions have confirmed this). In that sense OpenSSL is already too strict: if AKID completely mismatches it will decide that the candidate certificate cannot be an issuer. I don't understand the usefulness of the AKID then. If it's only a hint and can't even be used to exclude certain certificates as issuers, what is it good for? Disclaimer: I'm just echoing what has been discussed in the PKIX list here no passing an opinion ;-) That said that AKID can be used to prefer one certificate issuer over another during path discovery. I'd interpret that to mean that (all things being equal) if there are two certificates one of which matches AKID and the other does not you would use the AKID match one. However by itself AKID mismatch should not exclude a certificate as an issuer. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3349] (Proposed PATCH) Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
On Thu, May 08, 2014, Viktor Dukhovni wrote: On Thu, May 08, 2014 at 05:12:07PM +0200, Dr. Stephen Henson wrote: I don't understand the usefulness of the AKID then. If it's only a hint and can't even be used to exclude certain certificates as issuers, what is it good for? Disclaimer: I'm just echoing what has been discussed in the PKIX list here no passing an opinion ;-) That said that AKID can be used to prefer one certificate issuer over another during path discovery. I'd interpret that to mean that (all things being equal) if there are two certificates one of which matches AKID and the other does not you would use the AKID match one. However by itself AKID mismatch should not exclude a certificate as an issuer. The Postfix 2.11 DANE code relies on certificates with skid != akid-keyid failing X509_check_issued(cert, cert) even though the subject and issuer DNs may be the same. I really hope that OpenSSL will not in the future break this assumption. To retain compatibility the X509_check_issued behaviour wont change. The certificate verify algorithm may be more lenient of mismatches in future in the absence of an exact match. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Reading the public key of a certificate created with RSA PSS
We want to read the public key of certificates created with an RSA PSS key. Using 'openssl x509 -inform DER -in test.cer -text' returns ... Subject Public Key Info: Public Key Algorithm: rsassaPss Unable to load Public Key 3000:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:239: 3000:error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm:.\crypto\asn1\x_pubkey.c:155: ... The other parts of the certificate are shown correctly. Used openssl version is 1.0.1g. Not sure if this is our mistake or not supported by openssl. But it works with certificates created with standard RSA keys. Eventually we want to use libeay32.dll directly. We already did this successfully in the past but found now X509_get_pubkey() returning NULL using such certificates. - Maybe there exists an alternative way to read out the public key to get a pointer to an EVP_PKEY structure? Regards, Michael -- View this message in context: http://openssl.6102.n7.nabble.com/Reading-the-public-key-of-a-certificate-created-with-RSA-PSS-tp50021.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Here's more information for those who are interested... https://supportforums.cisco.com/announcement/12198406/heartbleed-patched-email-servers-fail-tls-connections-esas-80 On 05/06/2014 07:08 PM, Viktor Dukhovni wrote: On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote: The defect information is available at https://tools.cisco.com/bugsearch/bug/CSCuo25329. This defect is viewable to the public. You'll have to register for an account to view the data. After registering, the bug details are: Heartbleed patched email servers, fail TLS connections to ESAs 8.0 + CSCuo25329 Description Symptom: Machines installed with OpenSSL 1.0.1g patch fail to connect with Cisco Email Security Appliance Conditions: Cisco AsyncOS 8.0 for Email or later. Status: Fixed Known Affected Releases: 8.0.1 8.5.5 8.5.0 Severity: 1 Catastrophic So what we learn is that perhaps this problem is present in only the latest general availability release and two limited availability releases. If so, we can hope that customers running this release have support contracts, and the issue will not be with us for very long. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Reading the public key of a certificate created with RSA PSS
On Thu, 8 May 2014 09:23:26 -0700 (PDT) MichaelM michael.mut...@nexusgroup.com wrote: We want to read the public key of certificates created with an RSA PSS key. openssl doesn't support that afaik. There's actually a thing to understand here: You can use RSA-PSS both with normal old RSA keys and dedicated RSA-PSS-keys+certificates. The latter are rarely supported at all by any software. RSA-PSS-signatures with normal RSA keys are supported by openssl. I investigated this for my diploma thesis a few years ago and I only found one obscure java library that was able to actually create and use such dedicate pss keys. I'm interested: Who has created these certificates and what software was used there? -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: Reading the public key of a certificate created with RSA PSS
On Thu, May 08, 2014, MichaelM wrote: We want to read the public key of certificates created with an RSA PSS key. Using 'openssl x509 -inform DER -in test.cer -text' returns ... Subject Public Key Info: Public Key Algorithm: rsassaPss Unable to load Public Key 3000:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:.\crypto\evp\p_lib.c:239: 3000:error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm:.\crypto\asn1\x_pubkey.c:155: ... The other parts of the certificate are shown correctly. Used openssl version is 1.0.1g. Not sure if this is our mistake or not supported by openssl. But it works with certificates created with standard RSA keys. Eventually we want to use libeay32.dll directly. We already did this successfully in the past but found now X509_get_pubkey() returning NULL using such certificates. - Maybe there exists an alternative way to read out the public key to get a pointer to an EVP_PKEY structure? If you're just interested in this one certificate you can manually extract the key using asn1parse. It is possible to add an alias for this algorithm and then OpenSSL can handle the key directly. It wont however support the PSS semantics properly: i.e. the key can only be used for PSS and any parameter restrictions. For that reason this hasn't been done in the official sources. It would help if you could post the actual certificate or send it to me privately if you prefer. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3342] coverity issue 966577
Thanks Tim. Patch applied http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b6e69d284b79097d0d9e39996cbe59eae6bb36e2 http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=8e94fadd0b79491714401d89b338db27211b9819 Similar commits on 1.0.2, 1.0.1 and 1.0.0 branches. This also fixes coverity issue 966576. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3349] Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
On Thu May 08 15:49:11 2014, s...@pdflib.com wrote: I can confirm that with this patch applied my use case with X509_verify_cert() works as expected (misidentification of signing certificate as CRL issuer no longer occurs). Could you give me more details of this case? If possible if you could send the certificates and CRLs involved (privately if you wish). It may be possible to address this case in X509_verify_cert() itself. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
