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!
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 am trying to deploy my node-RED environment using CA certificate.
i have created the pem files using .p12 file by executing below commands
– openssl pkcs12 -in test.p12 -passin pass:Password -out keyfile.pem -nodes
– openssl pkcs12 -in test.p12 -passin pass:Password -out crtfile.pem -nodes
then i have uncommented the https code from settings.js file of node red
https: {
key: require("fs").readFileSync('keyfile.pem'),
cert: require("fs").readFileSync('crtfile.pem')
}
i have used default http node and made the following configuration to the tls config
when i deploy the node i get the following error
"Error: unable to verify the first certificate"
what am i missing here?
Remove the changes you made to the settings.js. That section is only for if you want to have Node-RED serve the editor via TLS.
Next your openssl commands to export the user'sprivate key and certificate should probably be more like
openssl pkcs12 -in test.p12 -out keyfile.pem -passin pass:Password -nocerts
openssl pkcs12 -in test.p12 -out crtfile.crt -passin pass:Password -nokeys -clcert
You should also export the include CA chain with
openssl pkcs12 -in test.p12 -out ca.crt -passin pass:Password -cacerts -nokeys
You then need to add the ca.crt file to the HTTP node's TLS config.
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.
I do have private key(my_ca.key) and public key(my_cert.crt) which is signed by DigiCert. Now I want to create RA(Registration Authority) and sign it by my private key . Here is the way I tried to do that. But when I try to export private and public key as pkcs12 file I have been getting error like this unable to get local issuer certificate getting chain. No idea how to solve this. Here my_cert.crt is extended from DigiCert High Assurance CA-3 and that one extended from DigiCert High Assurance EV Root CA
SSL_SUBJ="/C=LK/ST=Colombo/L=Colombo/O=Nope/OU=mobile/CN=My root"
openssl genrsa -out ra.key 4096
openssl req -new -key ra.key -out ra.csr -subj "$SSL_SUBJ"
openssl x509 -req -days 365 -in ra.csr -CA my_cert.pem -CAkey my_ca.pem - set_serial 76964474 -out ra.crt
openssl rsa -in ra.key -text > ra_private.pem
openssl x509 -in ra.crt -out ra_cert.pem
openssl pkcs12 -export -out ca.p12 -inkey my_ca.pem -in my_cert.pem -name "cacert" -passout pass:password
openssl pkcs12 -export -out ra.p12 -inkey ra_private.pem -in ra_cert.pem - chain -CAfile my_cert.pem -name "racert" -passout pass:password
You usually can't use a certificate issued by a public CA to sign anything but client or server traffic; you won't be able to use it for your RA.
The error message indicates that there is a problem with the intermediate certificates. Make sure that you add both of Digicert's certificates to the my_cert.pem file before exporting it to pkcs12