I can use the openssl s_server command to accept TLS sessions from clients, and to require mutual TLS - i.e. request client certificate - using a command such as: -
openssl s_server -accept 4433 -cert myCert.crt -key -myKey.pem -Verify 2 -CAfile myCA.crt
When I connect from a client, I can see from tracing that s_client sends a certificate request, correctly stipulating the certificate contained within myCA.crt. However it seems that s_server will accept any client certificate, regardless of whether it was signed by myCA.crt or not - i.e. it doesn't care which client cert is sent.
Does anyone know if this is expected behaviour, or am I doing something wrong?
openssl s_server and s_client by default verify the peers certificate and show the verification status but don't stop on errors. If this is necessary use the -verify_return_error option.
I have an issue with the server rejecting the client certificate in the handshake if I issue openssl call with just the cert (with chain) and private key.
This issue goes away if I also set the cafile param and point it to the same file as the cert.
It seems as if openssl cannot construct the chain without the cafile input even if the information is already in the cert input. I wonder if you guys had experience with this. I just find it a bit odd.
To summarize, this works:
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem -CAfile cert_with_chain.pem
This doesn't work (Server reject with "null cert chain"):
sudo openssl s_client -connect <ip>:<port> -cert cert_with_chain.pem -key privkey.pem
Open SSL version:
OpenSSL 1.0.2k-fips 26 Jan 2017
The problem is not that "openssl cannot construct the chain without the cafile" but that it wasn't the intention in the first place to do so. The intended behavior is well documented in man s_client:
-cert certname The certificate to use, if one is requested by the server.
-CAfile file A file containing trusted certificates to use during server authentication and to use when attempting to build the client
certificate chain.
It may sound very simple but I can't get it to work. I want to connect to an ftp with ssl certificate on windows with command line.
So I generate my certificate with IIS, I export it to "cer" format and after a lot of try I end with this command line :
curl -3 -v --cacert "XX\XX\test_certif.cer" --disable-epsv --ftp-skip-pasv-ip --ftp-ssl ftp://XXXXXXX --user XXXX
and after entering my password, i have this error :
Enter host password for user 'XXXXXX':
* Rebuilt URL to: ftp://XXXX/
* Trying XX::XX:XX:XX...
* TCP_NODELAY set
* Connected to XXXXX (XX::XX:XX:XX:XX) port 21 (#0)
< 220 Microsoft FTP Service
> AUTH SSL
< 234 AUTH command ok. Expecting TLS Negotiation.
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: XX\XX\test_certif.cer
CApath: none
* SSLv3 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to XXX:21
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to XXX:21
And i out of idea to make it work.
To go a little further my ftp work when i change ssl parameter of the ftp from "Needed ssl connexion" to "allowed ssl connexion" so the matter is not this way.
And Windows firewall is disable.
update i still work on it and i have now this command line :
curl -v --cacert "XX\XX\test_certif.cer" --ftp-ssl ftp://XXX --user XXX
with this output
Enter host password for user 'XXX':
* Rebuilt URL to: ftp://XXX
* Trying XX::XX:XX:XX:XX...
* TCP_NODELAY set
* Connected to XXX (XX::XX:XX:XX:XX) port 21 (#0)
< 220 Microsoft FTP Service
> AUTH SSL
< 234 AUTH command ok. Expecting TLS Negotiation.
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: XX\XX\test_certif.cer
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
got any idea?
Feel free to ask more info if needed ill update the question.
Thx by advance
I solve my issue. The matter was with the certificat générate by IIS not working with curl.
So i use OpenSSl to générate a key :
openssl genrsa -des3 -out key.pem -passout pass:password 1024
Then still use OpenSSL to générate a certificat with the key :
req -x509 -new -key key.pem -passin pass:password -days 3650 -out certificat.cer -config "C:\Program Files (x86)\GnuWin32\share\openssl.cnf"
-config is not necessary needed and is located on the folder of your openssl install
Now still with OpenSSL, convert key+certificat to pfx
pkcs12 -inkey key.pem -in certificat.cer -export -out iis_certificate.pfx
Now you can import the pfx certificate to IIS and use it to configure your FTP connection.
Create a pem file and copy past the content of certificat.cer inside him or just convert the file to pem. Lets name it "cacer.pem"
Now use curl to connect :
curl -v ftp://"IP or server name" --user « username » --ftp-ssl --cacert « Path of cacer.pem file »
Here is a little bonus, the command line to upload a file and set passord in the command line :
curl -upload-file “Path of file to transfert” ftp://"IP or server name" --user « user »: « password » --ftp-ssl --cacert " Path of cacer.pem file "
I have a .pfx file, which can perfectly connect to the remote server when used on a windows client. I want to now connect to server using a linux client.
Problem 1) I used following openssl commands to extract public cert and private key from the pfx file,
openssl pkcs12 -in Name.pfx -nocerts -out priv.pem -nodes
openssl pkcs12 -in Name.pfx -nokeys -out pub.pem
But when I ran following two commands to verify md5 of both files, I found both of them different.
openssl rsa -noout -text -in priv.pem | openssl md5
openssl x509 -noout -text -in pub.pem | openssl md5
Problem 2) I instead used following command to extract single pem file from pfx that has both cert and key.
openssl pkcs12 -in Name.pfx -out bundle.pem
Using this pem file I tried connecting to the remote server, with following command :
openssl s_client -servername 1.2.3.4 -connect 1.2.3.4:1234 -CAfile bundle.pem -state -tls1_2
This gives following output on terminal
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 O = "My Name", CN = Name - Local
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client certificate A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL3 alert read:fatal:handshake failure
SSL_connect:failed in SSLv3 read finished A
140250807310240:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
140250807310240:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
Certificate chain
0 s:/O=My Name /CN=Name - Local
i:/O=My Name /CN=Name - Local
---
Server certificate
-----BEGIN CERTIFICATE-----
<random string of certificate>
-----END CERTIFICATE-----
subject=/O=My Name /CN=Name - Local
issuer=/O=My Name /CN=Name - Local
---
No client certificate CA names sent
Server Temp Key: ECDH, secp521r1, 521 bits
---
SSL handshake has read 1332 bytes and written 206 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: <some string>
Session-ID-ctx:
Master-Key: <some string>
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1495217834
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
I cant figure out why is handshake failing. Stuck for 3 days, where exactly does problem lie.
But when I ran following two commands to verify md5 of both files, I found both of them different.
openssl rsa -noout -text -in priv.pem | openssl md5
openssl x509 -noout -text -in pub.pem | openssl md5
The first command shows textual information about the private key. The second textual information about the certificate which contains the public key. Of course these information are different.
Using this pem file I tried connecting to the remote server, with following command :
openssl s_client -servername 1.2.3.4 -connect 1.2.3.4:1234 -CAfile bundle.pem -state -tls1_2
This uses the certificate as a trusted CA (-CAfile). This is probably not what you want. Instead you want to use the certificate as a client certificate. This should be done as documented by using the options -cert and -key, i.e. -cert bundle.pem -key bundle.pem in your case.
Apart from that -servername should be a hostname and not an IP address. If you don't have a hostname skip this option.
SSL_connect:SSLv3 read server certificate request A
...
SSL_connect:SSLv3 write client certificate A
...
SSL3 alert read:fatal:handshake failure
Since you don't specify the client certificate properly an empty client certificate will be send. But the server expects a valid client certificate and thus report a failed handshake within an SSL alert back to the client.
I'm trying to connect to a service that requires a certificate for authorization. The process is that I send the service a CSR file. The service signs the CSR and sends me a certificate that I use for connection.
I generated the CSR by the following command line:
openssl req -new -nodes -newkey rsa:2048 -keyout cert.key -out cert.csr
I took the content of the cert.csr and sent to them. They generate the client certificate and I got a PEM file back.
I now try to connect using their certificate file in SSLCERT for curl() and providing the private key from cert.key as CURLOPT_SSLKEY - (which I got at step 1).
Fails with: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
What am I doing wrong in this process?
It works when I try with a received a test certificate including a private key from the service (self signed certificate). But when I use a certificate they generated from my CSR and then use my private key as key, it errors with handshake failure.
So I know it does not have something to do with that openssl / curl doesn't support v3/TLS etc. that others when researching for a solution found out their problem was.
Here is what I run:
curl -i -v --request POST https://service.com/ --cert clientcert.pem --key private_key.pem --cert-type pem --tlsv1.1 --insecure
* Connected to service.com (1xx.xxx.xxx.xx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS handshake, CERT verify (15):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS alert, Server hello (2):
* error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
* Closing connection 0
Running following versions: curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Not a definite answer but too much to fit in comments:
I hypothesize they gave you a cert that either has a wrong issuer (although their server could use a more specific alert code for that) or a wrong subject. We know the cert matches your privatekey -- because both curl and openssl client paired them without complaining about a mismatch; but we don't actually know it matches their desired CA(s) -- because your curl uses openssl and openssl SSL client does NOT enforce that a configured client cert matches certreq.CAs.
Do openssl x509 <clientcert.pem -noout -subject -issuer and the same on the cert from the test P12 that works. Do openssl s_client (or check the one you did) and look under Acceptable client certificate CA names; the name there or one of them should match (exactly!) the issuer(s) of your certs. If not, that's most likely your problem and you need to check with them you submitted your CSR to the correct place and in the correct way. Perhaps they have different regimes in different regions, or business lines, or test vs prod, or active vs pending, etc.
If the issuer of your cert does match desiredCAs, compare its subject to the working (test-P12) one: are they in similar format? are there any components in the working one not present in yours? If they allow it, try generating and submitting a new CSR with a subject name exactly the same as the test-P12 one, or as close as you can get, and see if that produces a cert that works better. (You don't have to generate a new key to do this, but if you choose to, keep track of which certs match which keys so you don't get them mixed up.) If that doesn't help look at the certificate extensions with openssl x509 <cert -noout -text for any difference(s) that might reasonably be related to subject authorization, like KeyUsage, ExtendedKeyUsage, maybe Policy, maybe Constraints, maybe even something nonstandard.
If all else fails, ask the server operator(s) what their logs say about the problem, or if you have access look at the logs yourself.
What SSL private key should be sent along with the client certificate?
None of them :)
One of the appealing things about client certificates is it does not do dumb things, like transmit a secret (like a password), in the plain text to a server (HTTP basic_auth). The password is still used to unlock the key for the client certificate, its just not used directly to during exchange or tp authenticate the client.
Instead, the client chooses a temporary, random key for that session. The client then signs the temporary, random key with his cert and sends it to the server (some hand waiving). If a bad guy intercepts anything, its random so it can't be used in the future. It can't even be used for a second run of the protocol with the server because the server will select a new, random value, too.
Fails with: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Use TLS 1.0 and above; and use Server Name Indication.
You have not provided any code, so its not clear to me how to tell you what to do. Instead, here's the OpenSSL command line to test it:
openssl s_client -connect www.example.com:443 -tls1 -servername www.example.com \
-cert mycert.pem -key mykey.pem -CAfile <certificate-authority-for-service>.pem
You can also use -CAfile to avoid the “verify error:num=20”. See, for example, “verify error:num=20” when connecting to gateway.sandbox.push.apple.com.
The solution for me on a CentOS 8 system was checking the System Cryptography Policy by verifying the /etc/crypto-policies/config reads the default value of DEFAULT rather than any other value.
Once changing this value to DEFAULT, run the following command:
/usr/bin/update-crypto-policies --set DEFAULT
Rerun the curl command and it should work.
In my case the cause of the error was that I only imported the certificate (e.g., cert1.pem) and the private key (e.g., privkey1.pem) into the keystore and to solve the issue, I had to import the full chain of certificates as well.
I got the following files from "Let's Encrypt" certification authority:
privkey1.pem
fullchain1.pem
chain1.pem
cert1.pem
So I did the following:
Join the content of three certificate files together into a file named all.pem:
cat cert1.pem chain1.pem fullchain1.pem > all.pem
Create my keystore containing the full certificate chain:
openssl pkcs12 -export -in all.pem -inkey privkey1.pem -out my_keystore.p12 -name mycertalias -CAfile chain1.pem -caname root