I am trying to run the following command:
[root#localhost certs]# openssl s_client -connect localhost:7043 -cert /opt/openssl-1.0.0a/ssl/certwork_client/client.crt -key /opt/openssl-1.0.0a/ssl/certwork_client/client.key -CAfile /opt/openssl-1.0.0a/ssl/certwork/ca.crt -showcerts -state -verify 2
verify depth is 2
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=1 C = US, ST = Florida, L = Orlando, O = Company XYZ, OU = MyApp, CN = MyApp CA
verify return:1
depth=0 C = US, ST = Florida, L = Orlando, O = Company XYZ, OU = MyApp, CN = MyApp Manager Server
verify return:1
SSL_connect:SSLv3 read server certificate 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 certificate verify A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL3 alert read:fatal:unknown CA
SSL_connect:failed in SSLv3 read finished A
15238796:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca:s3_pkt.c:1193:SSL alert number 48
15238796:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
---
Certificate chain
0 s:/C=US/ST=Florida/L=Orlando/O=Company XYZ/OU=MyApp/CN=MyApp Manager Server
i:/C=US/ST=Florida/L=Orlando/O=Company XYZ/OU=MyApp/CN=MyApp CA
-----BEGIN CERTIFICATE-----
MIIFWDCCA0ACAQEwDQYJKoZIhvcNAQEFBQAwajELMAkGA1UEBhMCVVMxEDAOBgNV
BAgMB0Zsb3JpZGExEDAOBgNVBAcMB09ybGFuZG8xGDAWBgNVBAoMD0xvY2toZWVk
IE1hcnRpbjEMMAoGA1UECwwDTkNSMQ8wDQYDVQQDDAZOQ1IgQ0EwHhcNMTEwMzA4
MTc0MzQ3WhcNMjEwMzA1MTc0MzQ3WjB6MQswCQYDVQQGEwJVUzEQMA4GA1UECAwH
RmxvcmlkYTEQMA4GA1UEBwwHT3JsYW5kbzEYMBYGA1UECgwPTG9ja2hlZWQgTWFy
dGluMQwwCgYDVQQLDANOQ1IxHzAdBgNVBAMMFk5DUiBTQU4gTWFuYWdlciBTZXJ2
ZXIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDYCut4DlfOcEXXyN1F
jNwyhEqLcdfQEDNWZDoQ/R3PfN3uTJGhYGuAgAIJZccYHF4BTTjZ5BA2u9ASYMJV
dUcCFU+mvCf3K6SzTG1/v46jBZz+C9OsQVZqc6UA/EmQKYzlDecvtukpQ6cquHBa
02JxBD3W2oZzdNWYZW6dn82YfzQGcySQhpFJMyyjf0baPV9wFKNqot7ZNiyusQTJ
g/GL8c29UJXHBYw15UMHm0dlDl2FREWEdNfbGbZCU+QTpyS059itkgmNQRKgNdBh
JpmRBJLp+iIk29JoKFJTyADR/QtIFnv/gl3P7FFvy1AZ+dGLQTHcf/MIFsbpf+s8
J7FtT+i/dCnLVDsz5e29jaSP32D0wAs66+I7ik4hOA0Eicaykwau19zkXpt1qScI
cb9ynjiGmoKzN+0ESm+S0Mr8+CgzTpfrNqDkJEgW8CQQqv8gzIYXgued+86omFvy
Qiq5ISeY13XrzbwX8NmFsByvAzWQ+emfkTF7A2HbGSpaeXWVUUqnT+BKeLk1uuGV
L8oWIGYJdjQiUGapjcU0uMxef8PKtJp3O40bqDSb5d7wONtwgEURr8583fo9415N
EMCkPiddgRet0TRATmNGgBpMpkOR5lf1WI4lgBRvHUFObbbwI7ByPyxifYtMwSFG
HVEz2MWol2cgQGWGG77nBaxPYQIDAQABMA0GCSqGSIb3DQEBBQUAA4ICAQALpEtS
b2j1eKXPzdjqB9cN0TDc87j49+dPJiinQqHvCqLN3sPpXIXeh/mPGWL71s/4pQmS
rMZwe/0vmOI5tCvUCM84xtbCW07UvtiBcOpvFjdoW9KfCvPiPiIiPs0FNUcaYcdZ
y+bxgCHDLnk3FnNW4ECqHHIpio6bvKOJKEBB1DE0kBxzv4ayqHVeRTIBahVeIun2
5XftPiScRQE+b4//qozyU9v3gzbQ1UuEFvYgWAlmllneiRw2oLpazIOrLi3YJbie
wnPnbT1wM4b/JpVUSw41NAlVY5W2OujCcQWHNAWu3UW8GE0pLTFPj/DSAV+rkb0f
l1anvsmKly5oTcxEhi4lV6VhWabsJYag5uXZMViBoUK4hZRTXIgylVrvSZWpFTgO
vgeheOT2IJ1pXJRzuuB7/8pwvqliGDIeIccwvBzlIuY9mTehyX+uAfKKQwQ0IGDG
exPIVySi4HZi6rPNbO6Q17Tz6HYdlr1NMri82lLiOgjzNH8yPHXMSYjqtT3bG9a2
YWjYeNWjFtcyVOb60UXQRf+ghc2TDBii8pZ4u9dbsVoenzevFHc+k/8Ku6RAeMjo
+BqB7wzS39jAL+AmOa3XM0GI7h3Wrj0sZs2D32VejECzn6xat+NGKE+oZH0d2RKs
eVA5Vo+zKcEFskiWWBdPhG3Flqn8pfvMLpqoDA==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=Florida/L=Orlando/O=Company XYZ/OU=MyApp/CN=MyApp Manager Server
issuer=/C=US/ST=Florida/L=Orlando/O=Company XYZ/OU=MyApp/CN=MyApp CA
---
Acceptable client certificate CA names
/C=US/ST=Florida/L=Orlando/O=Company XYZ/OU=MyApp/CN=MyApp Client CA
---
SSL handshake has read 1615 bytes and written 3975 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 10AB798BBA57D06F61D0E970EF8919619942EC2A22131260C3718CA23ED75FD1
Session-ID-ctx:
Master-Key: D9EC43146764BAEE7E32A591C5A933914B57DA2EC479A6419EE3E822B3022E80E093798D1E17947159B7080F8AA80C85
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1299706827
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
In the server, I have the following code:
certificateFile = /opt/openssl-1.0.0a/ssl/certwork/server.crt
privatKeyFile = /opt/openssl-1.0.0a/ssl/certwork/server.key
ctx = Ctx::client_server(certificateFile, privateKeyFile);
ctx->context()->verify_mode = SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT | SSL_VERIFY_CLIENT_ONCE;
ctx->context()->client_CA = SSL_load_client_CA_file("/opt/openssl-1.0.0a/ssl/certwork_client/ca.crt");
The context() calls methods in OpenSSL’s ssl.h.
I created the server CA (certificate authority) and server certificates with the following commands:
cd /opt/openssl-1.0.0a/ssl
mkdir certwork
chmod 600 certwork
cd certwork
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
I created the client CA and client certificates with the following commands:
cd /opt/openssl-1.0.0a/ssl
mkdir certwork_client
chmod 600 certwork_client
cd certwork_client
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
openssl genrsa -des3 -out client.key 4096
openssl req -new -key client.key -out client.csr
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
I can get server-side authentication to work via certificates, but when I add client-side authentication using certificates, I get tlsv1 alert unknown ca:s3_pkt.c:1193:SSL alert number 48 error.
I setup the client to use the server’s CA (/opt/openssl-1.0.0a/ssl/certwork/ca.crt) and I setup the server to use the client’s CA file (/opt/openssl-1.0.0a/ssl/certwork_client/ca.crt).
What am I missing?
It seems to me the server is rejecting the client certificate.
There are 3 different CA settings for TLS server:
The server chain provided to the client (SSL_CTX_add_extra_chain_cert)
The CAs you announce to support to the client (SSL_CTX_set_client_CA_list)
The CAs you actually use to verify (SSL_CTX_load_verify_locations)
You might be configuring your server with the wrong equivalent in your bindings.
Have you tested with openssl s_server ?
what do you mean "I can get server-side authentication to work" ? Normally the server-side authentication is the last one; first the client verify the identity of your server, and then it send its certificate to server.
If the client recognized your server, it mean your client have CA certificate that signed the certificate of your server, OR your server certificate.
If the server doesn't recognize your client, check your server's truststore (in JAVA), or your CACertificateFile in your apache2 configuration ...
Hope it helps
I had this problem before. It turned out that I hadn't created the correct certificate, key and signature. This quick start guide was all I needed to create them.
Related
I'm using Mosquitto version 1.4.8 on my test PC and the server. The server is accessible via ha.euroicc.com.
I've generated certificates and keys using the following script:
#! /usr/bin/env bash
# Create the CA Key and Certificate for signing Client Certs
openssl genrsa -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
# Create the Server Key, CSR, and Certificate
openssl genrsa -out server.key 1024
openssl req -new -key server.key -out server.csr
# We're self signing our own server cert here. This is a no-no in production.
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
# Create the Client Key and CSR
openssl genrsa -out client.key 1024
openssl req -new -key client.key -out client.csr
# Sign the client certificate with our CA cert. Unlike signing our own server cert, this is what we want to do.
# Serial should be different from the server one, otherwise curl will return NSS error -8054
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt
# Verify Server Certificate
openssl verify -purpose sslserver -CAfile ca.crt server.crt
# Verify Client Certificate
openssl verify -purpose sslclient -CAfile ca.crt client.crt
I've put 'd', 'dd' and 'dddd' everywhere except for common name.
The common name for ca is 'd' and for server/client is 'ha.euroicc.com'.
CN for server/client needs to be this value, or it doesn't work at all!
My current mosquitto config file:
pid_file /var/run/mosquitto.pid
persistence true
persistence_location /var/lib/mosquitto/
persistence_file mosquitto.db
log_dest syslog
log_dest stdout
log_dest topic
log_type error
log_type warning
log_type notice
log_type information
connection_messages true
log_timestamp true
password_file /etc/mosquitto/passwd
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
allow_anonymous false
port 8883
cafile /etc/mosquitto/certs/ca.crt
keyfile /etc/mosquitto/certs/server.key
certfile /etc/mosquitto/certs/server.crt
require_certificate true
I use this command to subscribe from test PC:
mosquitto_sub -h ha.euroicc.com -t "topic/test" -u "damjan" -P "damjan" -p 8883 --cafile ca.crt --key client.key --cert client.crt
And get these errors:
On test PC:
Error: A TLS error occurred.
On server:
1532564086: OpenSSL Error: error:14089086:SSL
routines:ssl3_get_client_certificate:certificate verify failed
1532564086: Socket error on client <unknown>, disconnecting.
I've tried without require_certificate set on the server side, and not using client key/cert on the client side and subscription works in this case. This means that username/password parameters are fine.
That means that I either generated certificates and keys with a problem, my mosquitto.conf is bad or I'm using mosquitto_sub with a problem. Maybe something else?
I'm really at loss here and can't figure out what to try next...
Every bit of information helps.
Had a similar issue while upgrading to 2.0 because of the updated TLS/SSL bindings several know weak algorithms are not supported anymore.
In my case the signature of the certificate was sha1WithRSAEncryption where sha1 is the weak part. The same would be for e.g. MD5.
Check your certificate with openssl x509 -text -noout -in your.crt
Resigning the certificate with sha256WithRSAEncryption fixed it for me.
There is no need to create a new key.
You can either create a new CSR from your existing key and information from your certificate:
openssl x509 -x509toreq -in sha1.crt -signkey sha1.key -out sha256-new.csr -sha256
or overwrite the algorithm while signing the existing CSR again:
openssl x509 -req -days 360 -in sha1.csr -CA DummyCA-DonotTrust.pem -CAkey DummyCA-DonotTrust.pem -CAcreateserial -out sha256.crt -sha256
Recent openssl version should use sha256 as default.
Debian has changed the default setting with openssl-1.1.1 see https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 and set CipherString = DEFAULT#SECLEVEL=2.
To get a list of supported algorithms run: openssl ciphers -s -v 'ALL:#SECLEVEL=2'
Ok, so the problem was that I was generating all of the files on my test PC, and then sending it to the server.
I've tried generating everything on the server, and then copying appropriate files to my test PC, and everything works fine.
I've followed http://rockingdlabs.dunmire.org/exercises-experiments/ssl-client-certs-to-secure-mqtt . With lesser changes like hostname etc.
I had the same issue.
To fix it, while generating server.crt, answer to question 'Common Name' with IP address of the machine where Mqtt broker is going to be run.
I am trying to understand the relationship between the client and server in the context of an SSL connection. Am I correct in understanding that the fact that the same certificate authority (me - in example below) sign both server and client certificate makes that they can communicate. Thus, that the server only accepts communication when client authenticates with client certificate signed by the same CA as the server certificate, and this is essential to the idea of an SSL connection?
(script underneath comes directly from http://blog.nategood.com/client-side-certificate-authentication-in-ngi)
# Create the CA Key and Certificate for signing Client Certs
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
# Create the Server Key, CSR, and Certificate
openssl genrsa -des3 -out server.key 1024
openssl req -new -key server.key -out server.csr
# We're self signing our own server cert here. This is a no-no in production.
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
# Create the Client Key and CSR
openssl genrsa -des3 -out client.key 1024
openssl req -new -key client.key -out client.csr
# Sign the client certificate with our CA cert. Unlike signing our own server cert, this is what we want to do.
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
server {
listen 443;
ssl on;
server_name example.com;
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;
ssl_client_certificate /etc/nginx/certs/ca.crt;
ssl_verify_client on;
The short answer is No. These are two separate aspects.
Here:
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;
You are configuring the server certificates which need to be trusted by the client.
And here:
ssl_client_certificate /etc/nginx/certs/ca.crt;
You configure the certification authority to verify your clients' certificates against.
"Must server and client certificate be signed by same CA in SSL"
Short answer is, it can be but not necessary.
To see why, let's break down the steps but without too much technical.
From your point of view when setting up the nginx server.
You want to achieve 2 goals.
Prove the identity of your server.
For this you get a CA to sign your server certificate and
present it to a client that connects to your server
Verify the identity of the client connecting to the server
For this, you set define the list of CA that you trust that signs the client's certificate.
When a client connects to your server, you check if the client certificate presented is signed by your list of CA
That's not the end. Let's look at the client's end.
The client also wants to achieve 2 goals.
Prove the client's identity when connecting to your server
For this, the client get a CA to sign its client certificate and
present it to your server when connecting.
Here is the catch, the CA that signs the client certificate must be in your server's list of CA.
Verify the identity of your server
For this, the client has to trust the CA that signs your server's certificate.
How is this done?
Typically this list is predefine on the system or browser so it happens transparently.
But if you are writing a client, then you may have to define this list of trusted CA or just let the client know the CA that signs your server certificate.
So, it can happen that the CA signing the server and the client is the same but it is not necessary. It all depends on the list of CA defined on both the server and the client.
Server certs and Client certs are used in completely different ways.
The only similarities are:
They both contain the word certificate
They both use public & private keys for encryption
I am creating a test network using raspberry pis. My computer will be the CA and my pi zero W the client. I have created a self-signed CA certificate on my computer, certificate request on the pi, and signed the request with the CA keys on my computer.
When I verify the certificate on the pi, I get an error. There is no error on my computer with the same command and same files
Error on raspberry pi:
$ openssl verify -verbose -CAfile ca.pem pi.pem
error 18 at 0 depth lookup: self signed certificate
error cert.pem: verification failed
# ca.pem is the ca self-signed cert. pi.pem is the cert signed by ca private key
using the SAME files on my computer:
$ openssl verify -verbose -CAfile ca.pem pi.pem
error cert.pem: verification failed
error 18 at 0 depth lookup: self signed certificate
OK
# ca.pem is the ca self-signed cert. pi.pem is the cert signed by ca private key
What I have tried so far
reinstall openssl on pi
replace openssl.cnf file with the one on the pi with the one on my computer
changed time on raspberry pi
switched roles: pi as CA and computer as client. This led to verification working on computer but not pi (as before)
raspbian version is stretch not sun
tried self signed certificate verification. Verify works on computer and pi.
The process for creating the certificates:
# Server: https://support.symantec.com/en_US/article.TECH242030.html
openssl req -new -sha256 -out cert.csr
openssl x509 -req -days 365 -in cert.csr -signkey privkey.pem -sha256 -out cert.crt
openssl x509 -in cert.crt -out ca.pem -outform PEM
# Client:
openssl req -new -sha256 -out pi.csr
openssl x509 -req -days 365 -in pi.csr -signkey privkey.pem -sha256 -out pi.crt # <--- privkey.pem is the privkey of CA
openssl x509 -in pi.crt -out pi.pem -outform PEM
You need some kind of configuration file for your CA certificate, otherwise it will use basicConstraints=CA:FALSE which means that it creates a self signed leaf certificate rather than a CA certificate. In other words, your certificate is trusted but not for signing other certificates.
See e.g. here how to create a chain.
https://gist.github.com/Soarez/9688998
Note that you also need to use e.g. -CA and -CAkey so please do not use your own commands and just a config file.
I am hosting a nginx webserver in my LAN and I want to authenticate client who are accessing my server with ssl client certificate.I generated a self signed SSL certificate and one client certificate following some documents on google. But I am unable to authenticate client who has certificate. I am getting the following errors
When requested from Firefox:
2017/08/10 18:30:13 [info] 8994#0: *4 client sent no required SSL certificate while reading client request headers, client: 192.168.16.27, server: 192.168.26.43, request: "GET /hls1/master.m3u8 HTTP/1.1", host: "192.168.26.43"
When request using curl:
curl -v -s -k --key client.key --cert client.crt --cacert ca.crt https://192.168.26.43/hls2/master.m3u8
2017/08/10 18:30:33 [info] 8994#0: *5 client SSL certificate verify error: (18:self signed certificate) while reading client request headers, client: 192.168.16.27, server: 192.168.26.43, request: "GET /hls2/master.m3u8 HTTP/1.1", host: "192.168.26.43"
So,my question is can I use self-signed certificate to authenticate client?If so, can anyone provide the steps to achieve this?
I just stumbled over this and discovered a small pitfall which caused the same error you encountered:
error 18 at 0 depth lookup: self signed certificate
There are plenty of guides how to create a self signed client certificate, I used the following (adapted from here):
# Create the CA Key and Certificate for signing Client Certs
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
# Create the Client Key and CSR
openssl genrsa -des3 -out client.key 4096
openssl req -new -key client.key -out client.csr
# Sign the client certificate with our CA cert
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
# Convert to .p12 so import in OSX works
openssl pkcs12 -export -clcerts -inkey client.key -in client.crt -out client.p12 -name "MyKey"
However, if you use the same Organization Name (eg, company) for both your ca and your client certificate, you will see above error! (edited: important)
If openssl verify -verbose -CAfile ca.crt client.crt does not complain about a self-signed certificate, you're good to go.
The server has to trust the client certificate. In the case of a self-signed certificate, that means the certificate has to be exported from the client's keystore and imported into the server's truststore.
When the server asks for the client certificate, it also sends a list of trusted signers, and the client is only allowed to send a certificate which is ultimately signed by one of those signers. As the server didn't know about the self-signed client certificate, it didn't include that as a trusted signer, so the client was unable to send its certificate. Hence client sent no required SSL certificate while reading client request headers.
I am trying to setup stunnel with certificate verification. I have put verify = 1 in stunnel.conf.
I generated a certificate for STunnel server and client and signed with CA (CA setup in lab) :
openssl req -out stunnel.csr -new -newkey rsa:2048 -nodes -keyout stunnel.key
scp stunnel.csr root#<CA IP Address>:/etc/pki/CA/csr/
openssl ca -extensions v3_ca -days 3650 -in csr/stunnel.csr -out certs/stunnel.pem
cat stunnel.key >> stunnel.pem
But when I use this cert I get error:
2014.05.07 17:01:56 LOG4[8343:140373923505920]: VERIFY ERROR: depth=1, error=unable to get issuer certificate: /C=US/ST=California/O=Org/OU=OrgUnit TLM/CN=CAHost
2014.05.07 17:01:56 LOG3[8343:140373923505920]: SSL_accept: 140890B2: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
2014.05.07 17:01:56 LOG5[8343:140373923505920]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
What is going wrong here ?
What is going wrong here ?
The error is 0x140890B2:
SSL_accept: 140890B2: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
The error string from OpenSSL is "no certificate returned".
If you supply the client certificate, then the problem will likely go away.