Re: Questions about using Elliptic Curve ciphers in OpenSSL
Anyone have any advice on Elliptic Curve? Thanks in advance. From: openssl-users on behalf of Jason Schultz Sent: Friday, February 7, 2020 2:58 AM To: openssl-users@openssl.org Subject: Questions about using Elliptic Curve ciphers in OpenSSL I’m somewhat confused as to what I need to do to use ECDHE ciphers (ECDHE-ECDSA-AES128-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, etc). I’m hoping this list can help, or at least point me to a good tutorial somewhere. A lot of the information I’ve looked at is from the following links: https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations https://crypto.stackexchange.com/questions/19452/static-dh-static-ecdh-certificate-using-openssl I’m only looking at getting something set up for testing for now; I have a self-signed certificate and a private key. Here is the certificate, with some info stripped (I didn’t create it so I don’t have the exact commands used): Certificate: Data: Version: 3 (0x2) Serial Number: e7:64:34:3c:f2:b4:f5:cc Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, ST=MyState, L=City, O=Org, OU=Dept, CN=MyCN/emailAddress=m...@example.com Validity Not Before: Jan 29 20:11:44 2020 GMT Not After : Jan 28 20:11:44 2021 GMT Subject: C=US, ST= MyState, L=City, O=Org, OU=Dept, CN=MyCN/emailAddress=m...@example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65: 31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c: 74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02: 89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07: 58:68:82:a4:3e ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Subject Key Identifier: DA:B7:A7:5A:16:85:40:61:36:D7:37:5E:AF:BE:E4:90:80:05:C7:FA X509v3 Authority Key Identifier: keyid:DA:B7:A7:5A:16:85:40:61:36:D7:37:5E:AF:BE:E4:90:80:05:C7:FA X509v3 Basic Constraints: CA:TRUE Signature Algorithm: ecdsa-with-SHA256 30:45:02:21:00:bc:9c:cb:f1:ca:30:24:d3:7e:86:b4:d4:6f: f6:5a:3c:ab:c2:8d:24:b5:bc:03:b2:f9:55:74:0d:5d:cc:2c: 11:02:20:56:f8:05:4d:88:e6:35:ab:7b:db:01:02:1c:3d:ae: ab:5d:5a:86:61:5b:e5:2d:1a:3f:4d:bf:5b:ea:12:c2:50 I also didn’t generate the private key, but I’ll dump some info on it here, again to make sure it looks OK. It’s also part of the equation that I’m not 100% sure about (if my private key is set up correctly). This is a non-production key, used only for initial testing: ---:/etc/ssl # openssl ec -in private/mykey.pem -text read EC key Private-Key: (256 bit) priv: 00:96:f8:5b:9d:a3:fb:3d:27:de:01:75:54:0f:51: 69:38:d1:8f:2d:62:19:80:67:14:4a:da:1e:b5:d8: 57:8f:e8 pub: 04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65: 31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c: 74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02: 89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07: 58:68:82:a4:3e ASN1 OID: prime256v1 NIST CURVE: P-256 writing EC key -BEGIN EC PRIVATE KEY- MHcCAQEEIJb4W52j+z0n3gF1VA9RaTjRjy1iGYBnFEraHrXYV4/ooAoGCCqGSM49 AwEHoUQDQgAEHwfn6gm0lD6pC8TG0mUx20ycM5zN+734sQ6OaVx0zY2YDGcJ+x0B n/aI1AKJnWZ4/840CecFzGMfUwdYaIKkPg== -END EC PRIVATE KEY- ---:/etc/ssl # openssl ec -in private/mykey.pem -text -param_out read EC key Private-Key: (256 bit) priv: 00:96:f8:5b:9d:a3:fb:3d:27:de:01:75:54:0f:51: 69:38:d1:8f:2d:62:19:80:67:14:4a:da:1e:b5:d8: 57:8f:e8 pub: 04:1f:07:e7:ea:09:b4:94:3e:a9:0b:c4:c6:d2:65: 31:db:4c:9c:33:9c:cd:fb:bd:f8:b1:0e:8e:69:5c: 74:cd:8d:98:0c:67:09:fb:1d:01:9f:f6:88:d4:02: 89:9d:66:78:ff:ce:34:09:e7:05:cc:63:1f:53:07: 58:68:82:a4:3e ASN1 OID: prime256v1 NIST CURVE: P-256 writing EC key -BEGIN EC PARAMETERS- BggqhkjOPQMBBw== -END EC PARAMETERS- For my server code, the setup I use is very similar to if I was using an RSA certificate/key pair; setting up a CTX and calling the appropriate APIs for specifying the private key and certificate. Pseudocode: ctx = SSL_CTX_new(TLS_method()); status = SSL_CTX_use_PrivateKey_file(ctx,,SSL_FILETYPE_PEM); status = SSL_CTX_use_certificate_file(ctx, ,,SSL_FILETYPE_PEM); // Verify the cert and key are a pair status = SSL_CTX_check_private_key(ctx); I do some validation of the certificate, the code for which I’ll skip as I don’t think it’s important here. I also set the protocol version I support with SSL_CTX_set_max_proto_version() and call SSL_CTX_set_cipher_list() to set the ciphers the server supports. The ciphers include the following:
Re: Are RAND_bytes and RAND_priv_bytes thread safe?
Yes. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 11 Feb 2020, at 9:56 am, Hal Murray wrote: > > I didn't find any mention of threads in their man pages. > > > -- > These are my opinions. I hate spam. > > >
Are RAND_bytes and RAND_priv_bytes thread safe?
I didn't find any mention of threads in their man pages. -- These are my opinions. I hate spam.
Re: Problems adding specific extensions to signed certificates
On Fri, Feb 7, 2020 at 4:02 PM Michael Wojcik wrote: > > > From: Michael Leone [mailto:tur...@mike-leone.com] > > Sent: Friday, February 07, 2020 13:13 > > > > I've got it almost all figured out, except how to get a subjectAltName > > automatically populated by the CN of the requestor. My requests aren't > > asking for a SAN, but Chrome isn't happy without one, so I'd like to > > at least auto-populate 1 SAN by having it be the DNS: of the > > requesting CSR. > > > Not automatically, unfortunately. openssl ca recognizes a special > "email:copy" token in the extension list in the configuration file, but > that's only for email addresses in the Subject DN. Here's what I did. I created a file with a section name, and a SAN name: $ sudo more cert-extensions [ PHA_extensions ] subjectAltName=DNS.1: I then call that out, when I sign: $ sudo openssl ca -days 3650 -in requests/request.CSR.txt -out certs/2020-02-10.pem -extensions PHA_extensions -extfile cert-extensions -policy policy_anything That way, I can write up step-by-step HOWTOs, for the other folks in the department to whom using the command line is an obsolete and dinosaur way of computing (don't ask ..), and just tell them they have to create a simple text file with the specific alt name(s) wanted, and copy that, along with the CSR, over to the Linux VM for signing, and issue the above command. following the HOWTO. Eventually, I will be creating a Windows Intermediate CA, and that way I can just generate the certs that way, which is a lot easier, in an almost all Windows environment, using AD. And then I can turn off the Linux root CA, since I'll never use it again; I'll only use the intermediate CA. Thanks for all the help, everybody. It never occurred to me that I wasn't issuing certs the correct way, since the way I was issuing them, had always worked. Right up until I needed a SAN or certain extensions ...
Re: RSA-PSS - Backwards compatability - EVP_PKEY_get0_RSA
On 07/02/2020 18:14, Pedro Lopes wrote: > Hello, > > I'm assigning the RSA key as EVP_PKEY_RSA_PSS: > RSA* key; > EVP_PKEY_assign(*outKey, EVP_PKEY_RSA_PSS, key); > > As is known EVP_PKEY_get0_RSA was recently updated to also accepts > EVP_PKEY_RSA_PSS and return the rsa value. > > I'd like to know if there is any workaround to get the RSA key (RSA-PSS) . > I have to support openssl 1.0.1h and 1.1.1b. It's horrible, and it's a hack, but this would probably work: RSA *key = (RSA *)EVP_PKEY_get0(outkey) Matt
