I generated a ca-certificate, server-certificate and client-certificate using the guidelines of rabbitmq (https://www.rabbitmq.com/ssl.html#manual-certificate-generation)
But I keep getting an error Hostname mismatch when checking the certs with openssl s_server.
openssl s_server -accept 8443 -cert server_certificate.pem -key private_key.pem -CAfile ca_certificate.pem
openssl s_client -connect localhost:8443 -cert client_certificate -key private_key.pem -CAfile ca_certificate.pem -verify 8 -verify_hostname CN_NAME
RESULT:
Verify return code: 62 (Hostname mismatch)
When I read the hostnames, they both show the same..?
openssl x509 -in server_certificate -subject -noout
subject=CN = MyTestCA, O = server
openssl x509 -in client_certificate -subject -noout
subject=CN = MyTestCA, O = client
So I'm stuck why I'm getting the error 'Hostname mismatch'?
Related
Background: I create a self-made certificate and use the private key to sign some text.And then, use the self made certificate verify the signature.But I cannot verify successful.Here is my process.
# create Rsa public/private key
openssl genrsa -out private.key 2048
# generate the certificate
openssl req -x509 -days 3650 -key private.key -out ca.csr
# generate text message
echo 'hello' > text
# sign text
openssl smime -sign -inkey private.key -signer ca.csr -in text -outform PEM -out signature
# verify signature
openssl smime -verify -noverify -content text -certfile ca.csr -inform PEM -in signature -signer ca.csr
hello
Verification failure
139927005472576:error:21071065:PKCS7 routines:PKCS7_signatureVerify:digest failure:crypto/pkcs7/pk7_doit.c:1011:
139927005472576:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:crypto/pkcs7/pk7_smime.c:353:
what's wrong with my verification process.
In addition, if verify without -noverify option, which is in line with expectations
# verify signature
openssl smime -verify -content text -certfile ca.csr -inform PEM -in signature -signer ca.csr
Verification failure
139636965443472:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:336:Verify error:self signed certificate
I am testing many ciphersuites with NPS in Windows Server, with wireshark I am sniffing traffic to check which ciphersuite is using the handshake.
Now i am trying to test ECDHE ECDSA. In powershell I have enabled the ciphersuites but it's not working.
For example:
Ciphersuite --> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Certificate generation:
openssl ecparam -name brainpoolP384r1 -genkey -param_enc explicit -out private-key.pem
openssl ecparam -genkey -name secp384r1 -noout -out private-key.pem
openssl req -new -x509 -key private-key.pem -out certificate.pem -days 3000
cat private-key.pem certificate.pem > certificate-private.pem
openssl pkcs12 -export -inkey private-key.pem -in certificate-private.pem -out certificate-private.pfx
In Windows Server:
Enable-TlsCipherSuite -Name TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 -Position 0
And finally in wireshark:
ECDH ECDSA Ciphersuite
So I am not getting certificates for the followings ciphersuites
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Thanks all!
I made a tls server by below commands, which will request the client who is connecting to provide a client certificate. And I also simulated a client with the openssl commandline which will provide a client certificate. But it seems that the server didn't check if the client certificate is what exactly we want or not. Do you know how to make the server to do the check?
For the server:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes
openssl s_server -key key.pem -cert cert.pem -accept 44330 -Verify 0
For the client:
openssl req -x509 -newkey rsa:2048 -keyout clientkey.pem -out clientcert.pem -days 365 -nodes
openssl s_client -connect 127.0.0.1:44330 -cert clientcert.pem -key clientkey.pem
... check if the client certificate is what exactly we want or not
You do not specify what you want from the client certificate, that's why it cannot check it. If you want that the client certificate is signed by a specific CA use the -CAfile option as documented:
-CAfile infile
A file containing trusted certificates to use during client authentication and to use when attempting to build the server certificate chain. The list is also used in the list of acceptable client CAs passed to the client when a certificate is requested.
Thus, if you want to make sure that the client certificate is the self-signed certificate you issued (or some other certificate signed by this), use:
openssl s_server -key key.pem -cert cert.pem -accept 44330 -Verify 0 \
-CAfile clientcert.pem
How can disable the hostnameverfifier in gRPC to avoid exception below?
java.security.cert.CertificateException: No subject alternative names present
The recommended way to use test certificates where the hostname doesn't match is to call ManagedChannelBuilder.overrideAuthority("test-hostname"). This is functionally similar to adding test-hostname to /etc/hosts. This allows you to choose different IPs/DNS names with forAddress()/forTarget() without disabling security.
But it still seems like your certificate is a bit broken. Subject Alternative Name is required; using the certificate's Subject had been deprecated for a decades.
You may also be interested in using gRPC's test certificates. We provide TlsTesting to load them.
server = ServerBuilder.forPort(0)
// Use test cert on server-side
.useTransportSecurity(
TlsTesting.loadCert("server1.pem"),
TlsTesting.loadCert("server1.key"))
// ...
.build().start();
channel = NettyChannelBuilder
.forAddress("localhost", server.getPort())
// Trust test CA on client-side
.sslContext(
GrpcSslContexts.forClient()
.trustManager(TlsTesting.loadCert("ca.pem"))
.build())
// Change hostname to match certificate
.overrideAuthority("foo.test.google.fr")
.build();
Just to elaborate on #Eric Anderson answer. In the gRPC's test certificates he points to there are 2 types *.cnf files used to generate the client and server certs
1.Generate client cert: openssl.cnf
2.Generate server cert: server1-openssl.cnf
at the very bottom of both files you will find the hostnames where you need to add the matching entries for the client and server
for example if you are local testing for client and server resolving on "localhost" then you would need for both openssl.cnf and server1-openssl.cnf to have
[alt_names]
DNS.1 = localhost
after this you would need to regenerate the certificates
here is a simple script based on the grpc-java info here
#!/bin/bash
SERVER_CN=localhost
CLIENT_CN=localhost # Used when doing mutual TLS
TLS_KEY_PSSWD=somepsswd
echo "When prompted for cert information, everything is default except the common name which is set to localhost"
echo Generate CA key:
openssl genrsa -passout pass:TLS_KEY_PSSWD -des3 -out ca.key 4096
echo Generate CA:
openssl req -passin pass:TLS_KEY_PSSWD -x509 -new -nodes -key ca.key -out ca.pem -config conf/ca-openssl.cnf -days 3650 -extensions v3_req -subj "/CN=${SERVER_CN}"
echo "Now that we’re a CA on all our devices, we can sign certificates for any new dev sites that need HTTPS"
echo Generate client key:
openssl genrsa -out client.key.rsa 1024
openssl pkcs8 -topk8 -in client.key.rsa -out client.key -nocrypt
rm client.key.rsa
echo Generate client signing request:
openssl req -passin pass:TLS_KEY_PSSWD -new -key client.key -out client.csr -subj "/CN=${CLIENT_CN}"
echo Generate client cert:
openssl ca -passin pass:TLS_KEY_PSSWD -in client.csr -out client.pem -keyfile ca.key -cert ca.pem -verbose -config conf/openssl.cnf -days 3650 -updatedb
openssl x509 -in client.pem -out client.pem -outform PEM
echo Generate server key:
openssl genrsa -passout pass:TLS_KEY_PSSWD -out server1.key.rsa 1024
openssl pkcs8 -topk8 -in server1.key.rsa -out server1.key -nocrypt
rm server1.key.rsa
echo Generate server signing request:
openssl req -passin pass:TLS_KEY_PSSWD -new -key server1.key -out server1.csr -config conf/server1-openssl.cnf -subj "/CN=${CLIENT_CN}"
echo Generate server cert:
openssl ca -passin pass:TLS_KEY_PSSWD -in server1.csr -out server1.pem -keyfile ca.key -cert ca.pem -verbose -config conf/server1-openssl.cnf -days 3650 -extensions v3_req -updatedb
openssl x509 -in server1.pem -out server1.pem -outform PEM
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.