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.
Related
I had been able to get TLS connection with mosquitto and using CA.crt, server.crt, server.key plus client.crt and client.key. I been able to sub and pub no problem using MQTTfx and just command lines. below is my full setting for anyone who needs it, and I am looking for some help to use pfx certs.
I am asked to figure out how to sub and pub to the broker using PFX client cert(contains client.crt and client.key) along with ca.crt, which I don't see as option to MQTTfx 1.7 or in CMD examples I can find online. Wondering anyone had this experience using PFX that can enlighten me with broker settings and sub examples.
Broker setting:
listener 8883
log_type error
log_type notice
log_type information
log_type debug
require_certificate true
use_identity_as_username true
cafile C:\Program Files\mosquitto\cert\ca.crt
keyfile C:\Program Files\mosquitto\cert\server.key
certfile C:\Program Files\mosquitto\cert\server.crt
Subscription command line
mosquitto_sub -h 192.167.41.17 -t home/garden/fountain --cafile "C:\ca.crt" --cert "C:\client.crt" --key "c:\client.key" -d -p 8883
Certificates used in this project is self signed:
To create CA:
openssl genrsa -des3 -out ca.key 2048
openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
To create server:
openssl genrsa -out server.key 2048
openssl req -new -out server.csr -key server.key
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360
To create client:
openssl genrsa -out client.key 2048
openssl req -new -out client.csr -key client.key
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 360
To create the pfx:
openssl pkcs12 -export -out certbag.pfx -inkey client.key -in client.crt -in
mosquitto_pub & mosquitto_sub will only accept PEM encoded files for all certificates/key. There is no way directly use a PKCS12 (.p12 or .pfx) certificate store/bundle with these tools.
If version v1.7 of MQTT.fx (given the latest version if v5.0) also doesn't support being passed a PKCS12 bundle then there is no magic way you can make it, your only option is to use openssl to break it up into it's parts (cert, key and ca cert) encoded in PEM format and pass those files.
I have a basic nginx home server setup which i use Client certificates to allow outside access. I have followed this guide to get everything setup which works as expected:
https://gist.github.com/rkaramandi/20a04a41536f3d7e6d2f26b0b9605ab6
in summary:
openssl genrsa -aes256 -out ca.privkey 4096
openssl req -new -x509 -days 365 -key ca.privkey -out ca.crt
openssl genrsa -aes256 -out bobs-ipad.privkey 4096
openssl req -new -out bobs-ipad.csr -key bobs-ipad.privkey
openssl x509 -req -days 365 -in bobs-ipad.csr -CA ca.crt -CAkey ca.privkey -set_serial 100 -out bobs-ipad.crt
openssl pkcs12 -export -clcerts -in bobs-ipad.crt -inkey bobs-ipad.privkey -out bobs-ipad.p12
Also openssl pkcs12 -in bobs-ipad.p12 -out bobs-ipad.pem -nodes to generate a pem file as well.
And in nginx config:
ssl_client_certificate <path>/ca.crt;
# ssl_crl <path>/ca.crl;
ssl_verify_client optional;
...
location / {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
I am able to access the server from outside and only signed certificates on the client machine allow access.
However if one of the signed certificates were to be compromised i'd have to re-generate the CA and re-distribute the new signed client certificates. I understand that a CRL file can be used to revoke certificates using ssl_crl <path to crl>; in the nginx config but i am not sure to generate this using the guide i followed.
A command like this can be used openssl ca -gencrl -keyfile ca.privkey -cert ca.crt -out ca.crl
But this relies on a configuration file with an index of the certificates i believe?
Is there anyway of using a command like the above to input a (or list of) pem or p12 client certificate(s) -in bobs-ipad.pem that i want to revoke?
If not perhaps i need to start again and have a config with index file to then -revoke the certificates and re-generate the crl file.
Thanks in advance,
Richard
It doesn't seem like this is possible. I have found some other guides to get this working with a configuration file (and generating a new CA): https://arcweb.co/securing-websites-nginx-and-client-side-certificate-authentication-linux/
https://www.djouxtech.net/posts/nginx-client-certificate-authentication/
I am using Postman to test my API. I am using self-signed certificates to use HTTPS in my application.
After I turn on the HTTPS setup, the postman app shows this error
it shows
Error: self signed certificate
The API calls works perfectly when I turn off the SSL certificate verification in the postman setting. I tried to install certificate/keys in postman app but it didn't work.
I want to use the certificate/keys in postman so that I can hit the APIs using SSL. Is there any way to do that?
Generate RootCA.pem, RootCA.key & RootCA.crt:
openssl req -x509 -nodes -new -sha256 -days 1024 -newkey rsa:2048 -keyout RootCA.key -out RootCA.pem -subj "/C=BR/CN=Example-Root-CA"
openssl x509 -outform pem -in RootCA.pem -out RootCA.crt
customize waht you want...(C=?,CN=? etc)
Domain name certificate
Add your domain myapp.local that is hosted on your local machine for development (using the hosts file to point them to 127.0.0.1).
127.0.0.1 myapp.local
First, create a file domains.ext that lists all your local domains:
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = #alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = myapp.local
Generate localhost.key, localhost.csr, and localhost.crt:
openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=BR/ST=BAHIA/L=SSA/O=Example-Certificates/CN=localhost.local"
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile domains.ext -out localhost.crt
openssl pkcs12 -export -inkey localhost.key -in localhost.crt -out localhost.p12
customize waht you want...(C=?,CN=? etc)
For p12 uses 'password'. This was my keystore on springboot app for example:
Confguring a Keystore (used PKCS12 format, maybe a JKS format also acceptable)...
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-configure-ssl
cp localhost.p12 myapp/src/main/resources/keystore/localhost.p12
edit application.properties
# secure server port
server.port=8443
# The format used for the keystore. It could be set to JKS in case it is a JKS file
server.ssl.key-store-type=PKCS12
# The path to the keystore containing the certificate
server.ssl.key-store=classpath:keystore/localhost.p12
# The password used to generate the certificate
server.ssl.key-store-password=password
# Enable ssl
server.ssl.enabled=true
Trust the local CA
At this point, the site would load with a warning about self-signed certificates. In order to get a green lock, your new local CA has to be added to the trusted Root Certificate Authorities.
In Postman go to:
Settings -> Enable SSL certificate verification: ON.
Settings -> Certifcates -> CA Certificates: add the PEM RootCA.pem
In a curl command line:
curl --cacert RootCA.crt -v https://myapp.local:8449/endpoint
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 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.