[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
[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
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
Re: Reading the public key of a certificate created with RSA PSS
On Thu, 8 May 2014 09:23:26 -0700 (PDT) MichaelM 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: [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
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 #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
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 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. -- 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
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
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, 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 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
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: (Proposed PATCH): openssl req: 100% CPU with too long country name input
On Thu, May 08, 2014 at 09:16:16AM +0200, Jan-Benedict Glaw wrote: > 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 The below should fix it: diff --git a/apps/req.c b/apps/req.c index 316163f..41ed22c 100644 --- a/apps/req.c +++ b/apps/req.c @@ -1486,7 +1486,12 @@ start: #ifdef CHARSET_EBCDIC ebcdic2ascii(buf, buf, i); #endif - if(!req_check_len(i, n_min, n_max)) goto start; + if(!req_check_len(i, n_min, n_max)) + { + if (batch || value) + return 0; + goto start; + } if (!X509_NAME_add_entry_by_NID(n,nid, chtype, (unsigned char *) buf, -1,-1,mval)) goto err; ret=1; @@ -1545,7 +1550,12 @@ start: #ifdef CHARSET_EBCDIC ebcdic2ascii(buf, buf, i); #endif - if(!req_check_len(i, n_min, n_max)) goto start; + if(!req_check_len(i, n_min, n_max)) + { + if (batch || value) + return 0; + goto start; + } if(!X509_REQ_add1_attr_by_NID(req, nid, chtype, (unsigned char *)buf, -1)) { __ 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 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
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
[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 #include #include #include #include #include #include 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.org #3348] CMS_decrypt_set1_pkey() and key agreement
Hello Openssl Team, I've got a problem with CMS key agreement support. The command line I use is openssl cms -decrypt -inkey seckey.pem -in enc.agree -inform der When we enter the CMS_decrypt_set1_pkey() and do not have the cert, it iterates all the recipient structs, but skips all that is NOT key transport. So we skip everything and output contains random data. I think that if the key agreement is not supported here it is better to return error when no key transport structs are found. Thank you! -- SY, Dmitry Belyavsky __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[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 = digita
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