How do I know that my openssl generates TLSv1.2 - ssl

I need to generate a TLSv1.2 SSL certificate. I have done the following:
openssl genrsa -out myselfsigned.key 2048
openssl req -new -x509 -sha256 -key myselfsigned.key -out myselfsigned.cer -days 365 -subj /CN=<my localhost ip address>
Now how do I know that the certificate is actually a TLSv1.2 SSL certificate?

There is no such thing as a TLS 1.2 certificate.
There are RSA and ECDSA certificates which can be used with various TLS protocol versions and ciphers.
If TLS 1.2 is actually used depends on the capabilities and configuration of both client and server. You can check this when doing a packet capture and analyzing it with wireshark. Also there are often ways at server and client to find out which TLS version is in use by the current connection but how this is done depends on the client and server. For example with many browsers you get this information when clicking on the lock icon and then looking at the connection details.

Related

TLS: "wrong curve" error during client authentication

I have an Apache server that was recently upgraded from Debian 9 to Debian 10:
Apache : 2.4.25-3+deb9u13 => 2.4.52
Openssl: 1.1.0l-1~deb9u5 => 1.1.1n-0+deb10u1
Since this upgrade, connections from clients where client is authenticated (SSLVerifyClient require in Apache configuration) fails. Error in Apache debug logs is:
[Tue Apr 19 17:41:57.686913 2022] [ssl:error] [pid 19335] SSL Library Error: error:1414D17A:SSL routines:tls12_check_peer_sigalg:wrong curve
TLS_v1.2 was forced on server (Apache configuration: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 -TLSv1.3).
I made a wireshark capture and I am able to decode it. When authentication works (with Debian 9 version), messages exchanged are the following:
messagesExchange
When error occurs, The last "Finished" message sent by server is replaced by a TLS Alert (Level Fatal, Description: Illegal parameter).
This happens just after the client certificate is received by server, my conclusion is that the client certificate is not accepted by server.
Client certificate was generated by our PKI from a private key and a certificate signing request created on client using these commands:
openssl ecparam -genkey -name secp256k1 -noout -out ${PRIVATE_KEY}
openssl req -new -sha256 -key ${PRIVATE_KEY} -out ${CSR} -subj "/C=FR/O=XXX/OU=YYY/CN=ZZZ"
So curve used for this client certificate is secp256k1. This curve is not supported by TLS_v1.3.
If I create a private key using prime256v1 curve instead if using secp256k1, recreate CSR and certificate using the same PKI, I am able to connect to server without errors. Commands become:
openssl ecparam -genkey -name prime256v1 -noout -out /user/private_prime256v1.key
openssl req -new -sha256 -key /user/private_prime256v1.key -out /user/prime256v1.csr -subj "/C=FR/O=XXX/OU=YYY/CN=ZZZ"
So I assume my problem is linked to usage of secp256k1 curve in client certificates (and this new versions of Apache and Openssl).
I have tons of clients with certificates created from a private key using secp256k1 curve, so changing client certificates is not an option. I am looking for an Apache / mod_ssl / openssl configuration to accept client certificates using secp256k1 certificates even on this new version. I tried:
SSLOpenSSLConfCmd Groups "secp256k1:secp384r1:secp521r1:prime256v1:sect283k1:sect283r1:sect409k1:sect409r1:sect571k1:sect571r1"
without success.
There are many other parameters I can modify using SSLOpenSSLConfCmd but I didn't find any other configurations precisely linked to client authentication or to curves used in certificates.

RSA 2048 self signed certificate not being accepeted by NLB TCP listener

i am trying to create a self signed certificate using openssl following the docs https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-ssl.html
i tried to add the generated private and public pem files to my NLB TCP listener as a self signed certificate and it is failing with the below exception.
Error creating listener The imported certificate's configuration is not compatible and will not appear in the list of available certificates for your listeners. Select or upload a different certificate and try again.
I saw that NLB allows RSA 2048 certs. Not sure why the console is showing the error display.
You need to generate a RSA 1024 or 2028 certificate. check the valid certificates that ACM supports. i used the below commands to generate the self signed certificate
openssl genrsa -out private-key.pem 1024
openssl rsa -in private-key.pem -pubout -out public-key.pem
openssl req -new -x509 -key private-key.pem -out cert.pem -days 3600
mention the country, state and domain name. I initially missed the domain name because of which NLB listener wasn't accepting the certificate.

Generate self-signed certificate with specific cipher suites using OpenSSL?

I am trying to generate a self-signed server certificate with specific cipher suites supported:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
How should I proceed to generate the specific cert? I saw that most guides follow this command:
openssl req -new -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -out MyCertificate.crt -keyout MyKey.key
Should I be changing the -sha256 parameter?
Assuming you are talking about server certificates then in order to support those two ciphersuites your server will need an RSA certificate. The command that you listed will do that and will give you what you need.
Should I be changing the -sha256 parameter?
No, there is no need to do that. That specifies the digest to be used when signing the certificate. This is not related to the digest specified in the ciphersuite (SHA1).
X.509 certificate has nothing to do with cipher suite support. They are have no relations between each other. Certificate is used to authenticate entities (client and server). Symmetric algorithm selection is certificate-independent process and is handled by TLS server/client library separately.

Set ECDSA on Apache and get SSL_ERROR_NO_CYPHER_OVERLAP

thats my first post.
I will set up an Apache with ECDSA.
I generates this keys
secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
and generate a self-signed certificate.
openssl ecparam -name secp256k1 -genkey -param_enc explicit -out rootCA.key
openssl req -x509 -new -nodes -key server.key -sha256 -days 1024 -out rootCA.pem
At the ssl.conf I set
SSLCipherSuite ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384
Wireshark shows me that the client supports the cipher and i looked at firefox config
The same cipher but with RSA cert works without problems.
I showed enough Tutorials but i cant find the problem.
www.ssllabs.com/ssltest/ this test fails also with "Assessment failed: Failed to communicate with the secure server"
Have someone ideas what I can do?
You cannot use ECDSA ciphers if you don't present an ECDSA certificate.
openssl ecparam -name secp256k1 -genkey -param_enc explicit -out rootCA.key
Great this should have created an ECDSA private key. Now you need to make it into a certificate (possibly a self-signed certificate).
But in your following commands, you never use rootCA.key to make a certificate. Most probably you have generated an RSA certificate not ECDSA. Try to use -key rootCA.key in your openssl req command.

Mosquitto with SSL, Why do I generate .csr?

I am not familiar with SSL/TLS, I am trying to setup my moquitto broker with SSL. For testing purpose, I am not using a real rootCA, I create my own rootCA. Here is how I think what SSL is, correct me if I was wrong, I am a noob.
rootCA could issue second layer ca, cert, keys, and client/server exchange these information, when it needs to verify the identity of the others, it will bring these information to the rootCA and ask if that is correct.
so, I follow the documentation of Mosquitto, use OpenSSL to generate rootCA.crt, server.crt, server.key. I've also generated client.crt and client.key, so that when my client application connect to Mosquitto broker, the broker could identify that connection.
I added the ca file, key file, cert file configuration to my local.conf. Restart Mosquitto, it works.
Then I use mosquitto_sub with ca.crt, client.crt and client.key to connect to broker, that works out too.
What I don't understand is that, why does the documentation teaches me how to generate server.csr and client.csr?
I am guessing if I am not the rootCA, I need to send these csr to the real rootCA for those certificate to become legit, is that what csr is for?
.csr is a certificate sign request to be signed with your CA.crt and CA.key you won't need to use it on your mosquitto broker only CA.crt and client.crt/key are required. If you want to test it out Download MQTT.fx client to check your MQTT connection with these certifications. http://mqttfx.jensd.de/
The openssl command would be for example:
x509 -req -in client.csr -CA CA.crt -CAkey CA.key -CAcreateserial -out client.crt -days 365