I'm using ActiveMQ Artemis 2.17.0 replication with self-signed certificates. After trying to update to 2.18.0 I realized that something wrong with my certificates (see this thread). There is no SSL connections between brokers and clients.
Here is how I generated my certificates:
openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -days 365 -out brokerRoot.pem -subj "/C=US/ST=Maryland/L=Aberdeen/O=TestCompany/OU=IT/CN=test/emailAddress=test#gmail.com" -passin pass: passphrase
openssl pkcs12 -inkey private.key -in brokerRoot.pem -export -out broker_ks.p12 -password pass:keyStorePassword
keytool -import -alias broker -keystore client_ts.p12 -file brokerRoot.pem -deststoretype pkcs12 -storepass trustStorePassword -noprompt
and I'm using same client_ts.p12 and broker_ks.p12 on clients and on brokers. So the hostnames should match but it doesn't work anyway.
The ActiveMQ Artemis upgrade instructions for 2.18.0 references says:
...core clients will now expect the CN or Subject Alternative Name values of the broker's SSL certificate to match the hostname in the client's URL.
When you use the openssl command to create private.key you specify CN=test. This means your hostname must be test and your client should also use test in its URL.
Since it's not working my guess is that your hostname is not test. Therefore you need to change your SSL cert on the broker to use the proper CN value which matches the hostname of the broker and then use that in the client's URL.
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 have a Jenkins instance from which I need to call other services/endpoints which reside behind a load balancer. This load balancer requires and does SSL client certificate validation.
Is it possible to make Jenkins use an SSL client certificate for the calls it makes towards those endpoints residing behind that load balancer?
Something like below:
Jenkins call ---present_SSL_client_cert---> LB(verify client cert) ---> endpoint
Thank you in advance!
To get Jenkins to use a client cert for other endpoints start Jenkins with
JAVA_OPTS="-Djavax.net.ssl.keyStorePassword=changeme -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=/cert/jenkins.p12"
I used a normal client cert:
openssl req -nodes -newkey rsa:4096 -days 365 -keyout cert/jenkins.key -out cert/jenkins.csr -subj "/C=DE/ST=somewhere/L=inCity/O=someOrg/OU=someBla/CN=jenkins"
signed it:
openssl x509 -req -days 365 -in ../jenkins/cert/jenkins.csr -CA ca/ca.crt -CAkey ca/ca.key -out ../jenkins/cert/jenkins.crt -passin env:CA_KEY
and converted it to PKCS12:
openssl pkcs12 -nodes -export -in cert/jenkins.crt -inkey cert/jenkins.key -out cert/jenkins.p12 -certfile ../nginx/ca/ca.crt -passout pass:changeme
It was important use a non empty keyStorePassword, otherwise Jenkins threw an Exception java.security.UnrecoverableKeyException: Get Key failed: null
Furthermore I added the server cert to the Java keystore:
keytool -import -alias server.domain.de -keystore /usr/local/openjdk-8/jre/lib/security/cacerts -file /root/server.crt -noprompt -storepass changeit
I've tested this setup with jenkins:lts docker container and keycloak, both behind an nginx reverse proxy using client cert auth.
Using env-variables like JENKINS_HTTPS_KEYSTORE which one can sometime see for configuring Jenkins to use https itself did NOT work for client auth. I did not investigate further, but I assume the plugin OpenId Connect Authentication Plugin which I used did not honor this variable and uses basic java functionality.
We are try to set up the shield SSL in local machine.
Elasticsearch version : 2.2.1
Kibana version : 4.4.1
Shield version : Latest version
We generated self signed crt, key, pem file as below:
openssl req -out CSR.csr -new -newkey rsa:2048 -nodes -keyout privateKey.key
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
openssl req -out CSR.csr -key privateKey.key -new
openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key
openssl x509 -in certificate.crt -out certificate.pem
keytool -importcert -keystore node01.jks -file certificate.pem -alias my_ca
keytool -certreq -alias node01 -keystore node01.jks -file CSR.csr -keyalg rsa -ext san=dns:XXX.com,ip:XXXX.xxxx.xxx
keytool -importcert -keystore node01.jks -file Certificate-signed.crt -alias node01
openssl x509 -in Certificate-signed.crt -out node01-signed-noheaders.crt
and added in shield configuration.
Shield configuration:
shield.http.ssl: true
shield.transport.ssl: true
shield.ssl.keystore.key_password: XXXXX
shield.ssl.keystore.password: XXXX
shield.ssl.keystore.path: /es/config/shield/node01.jks
network.host: XX.XX.XX.XX
Kibana configuration:
elasticsearch.url: "https://XXXXX:9200"
elasticsearch.username: "username"
elasticsearch.password: "password"
elasticsearch.ssl.cert: /XXX/XXX/XXX/elasticsearchtls.crt
elasticsearch.ssl.key: /XXX/XXX/XXX/elasticsearchtls.key
elasticsearch.ssl.ca: /XXX/XXX/XXX/elasticsearch.pem
elasticsearch.ssl.verify: true
So when run the kibana the below error is displayed in elasticsearch log:
log [12:24:25.512] [error][elasticsearch] Request error, retrying -- self signed certificate
log [12:24:25.622] [warning][elasticsearch] Unable to revive connection: https://XXXX:9200/
log [12:24:25.624] [warning][elasticsearch] No living connections
log [12:24:25.627] [error][status][plugin:elasticsearch] Status changed from yellow to red - Unable to connect to Elasticsearch at https://XXXXXX:9200.
After that when I change the elasticsearch.ssl.verify: false Kibana is working fine, but showing some error in elasticsearch log:
ElasticsearchSecurityException[missing authentication token for REST request [/_mget?timeout=0&ignore_unavailable=true&preference=1461307913497]]
In elastic client also the same issue is coming. When we use rejectUnauthorized: true then client is not connecting to elasticsearch.
My questions are:
is the self signed certificate working in Elasticsearch, Kibana or not?
do we have to buy a commercial CA certificate?
are we missing anything?
You are using unnecessary steps when generating and importing the key. Also the certificate you are generating is not signed by the CA and hence it will never be trusted
Unless you have a large deployment I would just use a selfsigned certificate, rather than a certificate signed by a selfsigned CA.
1) Generate a selfsigned certificate with SAN extensions as indicated here How can I generate a self-signed certificate with SubjectAltName using OpenSSL?
2) Merge the key and certificate in a PKCS12 container and import it to the a java keystore as explained here importing an existing x509 certificate and private key in Java keystore to use in ssl
I am having issue configuring https on my aws elastic load balancer using a self-signed certificate. After I've done with the set up, making connection to https endpoint does not work. http connection is still fine.
Here's what I did.
Generate the self-signed certificate using this command
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt
Verified the key and certificate is working by using this command:
openssl rsa -in privateKey.key -check
openssl x509 -in certificate.crt -text -noout
Convert the certificate the key and the cert into a .pem encoded format to comply with aws certificate requirement.
openssl rsa -in privateKey.key -text > private.pem
openssl x509 -inform PEM -in certificate.crt > public.pem
Upload the certificate to my elastic load balancer using the the AWS Management Console
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_UpdatingLoadBalancerSSL.html. For the private key and public cert value, I used the private.pem and public.pem that were generated in step 3.
Go into EBL Listener configuration, added a https listener and used the certificate that I just uploaded. Here's the configuration for the Listener:
Any thought on what might be wrong in my configuration? Thanks!!!
Does the Security Groups of the Load Balancer include an inbound HTTPS 443 Port for source 0.0.0.0/0? I just spent a few hours until I finally found this solution.
I cannot seem to configure Dropwizard to use ssl.
I've created a key
openssl genrsa -des3 -out server.key 1024
and a certificate
openssl req -new -key server.key -days 365 -out server.crt -x509
and imported it into a keystore
keytool -import -file server.crt -keystore keystore.jks
From there, I've placed the keystore.jks file into /src/main/resources, alongside the config.yaml file for dropwizard.
Then I tried configuring ssl for dropwizard according to the manual:
http:
ssl:
keyStore: ./keystore.jks
keyStorePassword: ********
However, when I navigate to the login page, it only works without https: and gives Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error when using https.
Are there other steps that I'm missing?
I posted on the mailing list and Codahale was quick to respond. I hadn't set nonblocking+ssl connectors in my configuration yaml file under the http: section. Putting in
connectorType: nonblocking+ssl
fixed everything. Thanks dropwizard wizard!