I am following the F5 KB article to test SSL client based cert auth using openssl s_client but it keeps failing with this error:
OpenSSL> s_client -connect auc.akmlab.local:443 -key "C:\HELPAG\akmlab files\certs\admin-c-auth-ca-cert2.key" -cert "C:\HELPAG\akmlab files\certs\admin-c-auth-ca-cert.crt"
unable to load certificate
8204:error:0909006C:PEM routines:get_name:no start line:crypto\pem\pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
error in s_client
OpenSSL>
I am trying to google for this but cannot find much info anyway related to SSL client auth.
I have imported this same user cert to my browser and this works fine.
The server is a f5 bigip device with the root certificate from the CA which has signed the user certificated.
Related
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.
I have created a SSl certificate using these commands:
openssl genrsa -out kc_ca-key 2048
openssl req -new -out san_domain.csr -key kc_ca-key -config openssl.cnf
openssl x509 -req -days 3650 -in san_domain.csr -signkey kc_ca-key -out kc_ca-cert -extensions v3_req -extfile openssl.cnf
openssl.cnf file contains the common name, country name, subject alternative name and all such information.
In browser, I am able to connect securely after importing this certificate but when i run curl command with same certificate, i get the following error:
NSS error -8156 (SEC_ERROR_CA_CERT_INVALID)
* Issuer certificate is invalid.
* Closing connection 0
curl: (60) Issuer certificate is invalid.
More details here: http://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).
How to resolve this error
There is not enough information to determine what your problem is.
I am making the following assumptions:
You sent the certificate request (CSR) to a CA provider and got a certificate back.
You setup some sort of web server with that certificate
I am also assuming that you used a "Windows" web browser like IE or Chrome that uses the windows certificate store to test the certificate.
The CA that signed your certificate is a well known CA that has there root certificates in all the common CA Lists.
If the above is true and a web browser like Firefox (that uses it's internal CA list) fails it's because the web server is using a certificate without any intermediate certificates.
You need to go find the intermediate certificates for your CA signed certificate, combine them into a certificate chain and setup your web server with this certificate chain. The details of how to do this will depend on your web server.
Once the web server is setup with a correct certificate chain then your curl command (and firefox) should work fine.
The reason that windows works fine is because windows keeps a list of common intermediate certificates that it can verify a certificate chain with. A openssl based client doesn't, so the intermediate certificates have to come from the SSL socket server (e.g. web server) down to the client to be able to verify the certificate chain back to a trusted root certificate in the client CA list.
I have an application running on Centos7 that needs to connect to a remote host over HTTPS. However, it is unable to verify the certificate and fails. Also, if I try to download a file from the server using wget, I get the below error:
[root#foo:~]# wget https://10.65.127.9/index.html
--2017-05-22 09:03:01-- https://10.65.127.9/index.html
Connecting to 10.65.127.9:443... connected.
ERROR: cannot verify 10.65.127.9's certificate, issued by ‘/CN=us6877vnxe7827’:
Unable to locally verify the issuer's authority.
To connect to 10.65.127.9 insecurely, use `--no-check-certificate'.
So I get the certificate from the host:
openssl s_client -connect 10.65.127.9:443 <<<'' | openssl x509 -out /etc/pki/ca-trust/source/anchors/mycert.pem
And execute the following to process it:
update-ca-trust extract
This however results in the same issue.. If I run:
openssl s_client -connect 10.65.127.9:443 -showcerts -debug
I do get some errors and various messages:
depth=0 CN = us6877vnxe7827
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = us6877vnxe7827
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=us6877vnxe7827
i:/CN=us6877vnxe7827
Server certificate
subject=/CN=us6877vnxe7827
issuer=/CN=us6877vnxe7827
---
No client certificate CA names sent
---
Verify return code: 21 (unable to verify the first certificate)
Any ideas what I may be missing? If any further info helps, please let me know.
For wget you need to provide the certificate authority (CA) certificate(s) that signed the https server certificate. If you have those CA certificates - add them under --ca-certificate=file or --ca-directory=directory options
If you don't have them and you want to skip https server certificate verification (unsecure and can be dangerous) then use --no-check-certificate option.
I had the same problem with Jenkins trying to connect to our GitLab server.
The server does have a valid official certificate in our case, but Java didn't except it.
You are right about downloading the certificate.
However, the application you are mentioning is probably running inside a Java Virtual Machine (as a lot of applications are).
So from the point that you downloaded the certificate to a PEM file, you may have to add it to the VM's trusted certificates instead.
This article describes how to do that. Hope it helps.
I'm currently trying to connect to an EPP server using openssl s_client to verify my connection. The below command outputs the following.
openssl s_client -connect example.com:700
Response:
CONNECTED(00000003)
depth=1 /C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
41282:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL0 98-64.30.2/src/ssl/s3_pkt.c:1145:SSL alert number 40
41282:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.30.2/src/ssl/s23_lib.c:185:
I then proceeded to download the DigiCert SHA2 Secure Server CA from https://www.digicert.com/CACerts/DigiCertSHA2SecureServerCA.crt
I then re-attempted using a self-signed cert created with openssl, along with the new DigiCert certificate.
openssl s_client -connect example.com:700 -CAfile DigiCertSHA2SecureServerCA.crt -key key.pem -cert cert.pem -debug
And I get the same error. What could I be doing wrong here?
From the information you provide the client gets the certificate from the server and continues with the handshake but then gets a handshake_failure (alert 40) back from the server. Getting this error at this stage of handshake is likely caused by the server expecting to get a client certificate which the client did not provide. But, to be really sure one would need to have more information, ideally a full packet capture of the connection.
If you are using a self-signed certificate you should use the same file for both -CAfile and -cert. If you are using DigiCert CA in -CAfile then in -cert it should be a certificate signed by DigiCert.
Also the server needs to accept your certificate, which means it needs to have its CA (and possible intermediate CAs) beforehand.
I am testing ssl for rabbitmq locally. This setup consists of sever and client. I followed the instruction RabbitMQ SSL. I created ca, server, client certificates and keys. Everything worked.
But when I sent all those files to a colleague, who uses ubuntu, it didn't work for him. Whatever we tried connection between server and client didn't happen.
Although when we checked certificates on server and client using OpenSSL s_client and s_server to check that secure link can be established, connection was successful.
As described here https://www.rabbitmq.com/troubleshooting-ssl.html
openssl s_server -accept 8443 -cert server/cert.pem -key server/key.pem -CAfile testca/cacert.pem
openssl s_client -connect localhost:8443 -cert client/cert.pem -key client/key.pem -CAfile testca/cacert.pem
So my question is whether those keys and certificates can be just copied from OS to OS. Namely can CA be copied or should it be generated on every os separately?
I copy cacerts from os to os. But I generate keystore individually for each server because it is used to authenticate itself.