Re: [openssl-users] ecc negotiation
On 05/04/15 23:42, Matt Caswell wrote: On 05/04/15 22:04, David Rufino wrote: Hello, It's possible I'm doing something wrong here, but I can't seem to negotiate ecdhe with an elliptic curve other than P-256. To reproduce the issue, using openssl 1.0.2 openssl s_server -key server.key -cert server.crt -msg -debug -dhparam dhparam.pem -cipher ECDHE-RSA-AES128-SHA -tls1_2 gnutls-cli 127.0.0.1 -p 4433 -d 4 --insecure --priority=NORMAL:-KX-ALL:+ECDHE-RSA:-CURVE-ALL:+CURVE-SECP224R1 which gives the error :SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366: changing to p256r1 succeeds. is there a particular why the negotation would fail with p224 ? my understanding is that openssl supports all the nist curves. Try adding -named_curve secp224r1 to your s_server arguments. This specifies the curve to use for ECDHE keys. The default if you don't specify a named curve is P-256 which is why it works when you are using that curve. BTW, you can also use -named_curve auto, which will just pick an appropriate curve. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Is there any plan for FIPS to be supported on Linux-aarch64?
Hello, We are porting our products to Linux-aarch64. Our products are using OpenSSL with FIPS. I know that OpenSSL 1.0.2 started to support Linux-aarch64, but our products need OpenSSL FIPS as well. My question is when OpenSSL FIPS will be supported on Linux-aarch64? Thanks in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/Is-there-any-plan-for-FIPS-to-be-supported-on-Linux-aarch64-tp57389.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl is flexible when verifying
Hi, when I verify an X509 cert against a ca certificate, I found that the cert can pass validation even if it has two instances of X509v3 Basic Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some issues are not important in verification. (I guess one reason is that one subject key id is the same as the authority key id, and thus openssl may regard it as a self-signed certificate? ) Should this be forbidden? command: openssl verify -x509_strict -verbose -CAfile myroot.pem mycert.pem myroot.pem Description: application/x509-ca-cert myfile.pem Description: application/x509-ca-cert ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] ecc negotiation
On 05/04/15 22:04, David Rufino wrote: Hello, It's possible I'm doing something wrong here, but I can't seem to negotiate ecdhe with an elliptic curve other than P-256. To reproduce the issue, using openssl 1.0.2 openssl s_server -key server.key -cert server.crt -msg -debug -dhparam dhparam.pem -cipher ECDHE-RSA-AES128-SHA -tls1_2 gnutls-cli 127.0.0.1 -p 4433 -d 4 --insecure --priority=NORMAL:-KX-ALL:+ECDHE-RSA:-CURVE-ALL:+CURVE-SECP224R1 which gives the error :SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366: changing to p256r1 succeeds. is there a particular why the negotation would fail with p224 ? my understanding is that openssl supports all the nist curves. Try adding -named_curve secp224r1 to your s_server arguments. This specifies the curve to use for ECDHE keys. The default if you don't specify a named curve is P-256 which is why it works when you are using that curve. Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] ecc negotiation
Hello, It's possible I'm doing something wrong here, but I can't seem to negotiate ecdhe with an elliptic curve other than P-256. To reproduce the issue, using openssl 1.0.2 openssl s_server -key server.key -cert server.crt -msg -debug -dhparam dhparam.pem -cipher ECDHE-RSA-AES128-SHA -tls1_2 gnutls-cli 127.0.0.1 -p 4433 -d 4 --insecure --priority=NORMAL:-KX-ALL:+ ECDHE-RSA:-CURVE-ALL:+CURVE-SECP224R1 which gives the error :SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1366: changing to p256r1 succeeds. is there a particular why the negotation would fail with p224 ? my understanding is that openssl supports all the nist curves. Regards, David ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl is flexible when verifying
On Sun, Apr 5, 2015 at 5:26 PM, Yuting Chen che...@cs.sjtu.edu.cn wrote: I checked some other certificates, and found that some non self-signed certificates having duplicate extension instances can be verified by openssl. I guess openssl is quite gentle when validating these malformed certificates. Well, I don't think its OpenSSL per se in this instance. The underlying problem is the malleability in the standard. In this case, its RFC 5280 and: Applications are not required to verify that key identifiers match when performing certification path validation. - http://tools.ietf.org/html/rfc5280#section-4.2.1.2 In this case, there could be 1, 2, or 10 of them. And its not required that OpenSSL actually use any of them in path validation. (Rejecting a valid path due to an incorrect AKI is a different story). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl is flexible when verifying
I completely agree with Jeffrey's comments,
Applications are not required to verify that
key identifiers match when performing
certification path validation. (RFC5280)
But when the certificate has two authority
key ids, openssl may take it as a certificate
having no authority key ids (I think the certificate
is partially parsed and verified).
From the source code of openssl, it does
match the ids, if available (in v3_purp.c).
if(X509_NAME_cmp(X509_get_subject_name(issuer),
X509_get_issuer_name(subject)))
return X509_V_ERR_SUBJECT_ISSUER_MISMATCH;
x509v3_cache_extensions(issuer);
x509v3_cache_extensions(subject);
if(subject-akid)
{
int ret = X509_check_akid(issuer, subject-akid);
if (ret != X509_V_OK)
return ret;
}
On Sun, Apr 5, 2015 at 7:47 PM, Yuting Chen che...@cs.sjtu.edu.cn wrote:
Read a little code of openssl, and found that in
the function
X509_check_issued(X509 *issuer, X509 *subject),
The statement
x509v3_cache_extensions(subject);
is called for four times, but one certificate did not
get the subject keyid (as the block of if(subject-akid) is
called for three times). Seems that if the certificate
has two key ids, the verification is performed just on
the basis of their names (supposing that
subject-akid==NULL).
Not so sure about the correctness of my
reasoning. It could be better if we can discard
these certificates, as they will disturb the
verification.
On Sun, Apr 5, 2015 at 2:26 PM, Yuting Chen che...@cs.sjtu.edu.cn wrote:
I checked some other certificates, and found that some non self-signed
certificates having duplicate extension instances can be verified by
openssl. I guess openssl is quite gentle when validating these malformed
certificates.
On Sun, Apr 5, 2015 at 1:55 PM, Yuting Chen che...@cs.sjtu.edu.cn
wrote:
Hi, when I verify an X509 cert against a ca certificate, I found that
the cert can pass validation even if it has two instances of X509v3 Basic
Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some
issues are not important in verification. (I guess one reason is that one
subject key id is the same as the authority key id, and thus openssl may
regard it as a self-signed certificate? ) Should this be forbidden?
command: openssl verify -x509_strict -verbose -CAfile myroot.pem
mycert.pem
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl is flexible when verifying
I checked some other certificates, and found that some non self-signed certificates having duplicate extension instances can be verified by openssl. I guess openssl is quite gentle when validating these malformed certificates. On Sun, Apr 5, 2015 at 1:55 PM, Yuting Chen che...@cs.sjtu.edu.cn wrote: Hi, when I verify an X509 cert against a ca certificate, I found that the cert can pass validation even if it has two instances of X509v3 Basic Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some issues are not important in verification. (I guess one reason is that one subject key id is the same as the authority key id, and thus openssl may regard it as a self-signed certificate? ) Should this be forbidden? command: openssl verify -x509_strict -verbose -CAfile myroot.pem mycert.pem ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl is flexible when verifying
Read a little code of openssl, and found that in the function X509_check_issued(X509 *issuer, X509 *subject), The statement x509v3_cache_extensions(subject); is called for four times, but one certificate did not get the subject keyid (as the block of if(subject-akid) is called for three times). Seems that if the certificate has two key ids, the verification is performed just on the basis of their names (supposing that subject-akid==NULL). Not so sure about the correctness of my reasoning. It could be better if we can discard these certificates, as they will disturb the verification. On Sun, Apr 5, 2015 at 2:26 PM, Yuting Chen che...@cs.sjtu.edu.cn wrote: I checked some other certificates, and found that some non self-signed certificates having duplicate extension instances can be verified by openssl. I guess openssl is quite gentle when validating these malformed certificates. On Sun, Apr 5, 2015 at 1:55 PM, Yuting Chen che...@cs.sjtu.edu.cn wrote: Hi, when I verify an X509 cert against a ca certificate, I found that the cert can pass validation even if it has two instances of X509v3 Basic Constraints, X509v3 Subject Key ids, and authority key ids. Seems that some issues are not important in verification. (I guess one reason is that one subject key id is the same as the authority key id, and thus openssl may regard it as a self-signed certificate? ) Should this be forbidden? command: openssl verify -x509_strict -verbose -CAfile myroot.pem mycert.pem ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
