Recently I ran into the problem of generating a custom certificate that does not bind to 0.0.0.0 in Neo4j. It turns out that Neo4j - in contrast to the documentation - expects DER certificates for both the public and private key.
I will post lessons learned in respons to this question.
Rob
As of 3.0 this has been changed.
Open up /etc/neo4j/neo4j.conf and uncomment and change the following line:
# dbms.directories.certificates=/PATH/TO/YOUR/CERTIFICATES
Make sure that directory contains you certificate files named neo4j.key and neo4j.cert.
Make sure the files can be written by neo4j.
If you're using only .pem files, you can just rename those to .cert and .key, they're all plain text files, .pem is just an extension.
See the reference
Directory for storing certificates to be used by Neo4j for TLS connections.
Certificates are stored in the certificates directory, and are called neo4j.key and neo4j.cert.
sudo vi /etc/neo4j/neo4j-server.properties
uncomment org.neo4j.server.webserver.address=0.0.0.0
check: org.neo4j.server.webserver.https.enabled=true
check: org.neo4j.server.webserver.https.port=7473
change: org.neo4j.server.webserver.https.cert.location=/var/ssl/neo4j/server.crt
change: org.neo4j.server.webserver.https.key.location=/var/ssl/neo4j/server.key
now set up access to https
note: both the private key and the certificate need to be in DER format
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.pem
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.pem -CAkey ca.key -set_serial 01 -out server.pem
sudo mkdir -p /var/ssl/neo4j
sudo openssl x509 -outform der -in server.pem -out /var/ssl/neo4j/server.crt
sudo openssl rsa -in server.key -inform PEM -out /var/ssl/neo4j/server.key -outform DER
See also [my notes] (http://www.blaeu.com/nl/doku.php/Notes)
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 use self-signed CA cert to sign other certificates. For some certs I need to specify subject alternative names. I can specify them during request generation (openssl req ...) and I see them in .csr file. Then I sign it with CA cert using
openssl x509 -req -extensions x509v3_config -days 365 -in ${name}.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out ${name}.crt
and next sections in openssl.cnf file:
[ x509 ]
x509_extensions = x509v3_config
[ x509v3_config ]
copy_extensions = copy
but I see no SAN in .crt file.
I know about solutions with openssl ca ... command but I have no valid [ca] section and I don't want to copy/paste it without deep understanding what it does. So I hope that exists another solution with openssl x509 ... command.
The copy_extensions directive is only understood by the openssl ca command. There is no way to copy extensions from a CSR to the certificate with the openssl x509 command.
Instead, you should specify the exact extensions you want as part of the openssl x509 command, using the same directives you used for openssl req.
Sorry, I can't comment (yet).
In addition to #frasertweedale :
I generated my server-certificate with a config file
openssl req -new -out certificate.csr -key certificate_private_key.pem -sha256 -days 1825 -config certificate.conf
I then did
Instead, you should specify the exact extensions you want as part of the OpenSSL x509 command, using the same directives you used for OpenSSL req.
with the following command (I used the same .conf-file again):
openssl x509 -req -in certificate.csr -CA ca-root-public-certificate.pem -CAkey ca-key.pem -CAcreateserial -out certificate_public.pem -sha256 -days 1825 -extfile certificate.conf -extensions v3_req
There is a good documentation here : Certificates
You will need to compose an openssl conf file while creating a x509 cert request like this:
create CSR
openssl req -new -key server.key -out server.csr -config csr.conf
sign CERT
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000 -extensions v3_ext -extfile csr.conf
I have been having trouble configuring tensorflow to use ssl certificates. In run the experiments in my local machine. The tensorflow environment I am using is as specified in tensorflow/serving:1.14.0-gpu Dockerfile.
When calling the command:
tensorflow_model_server --port=9000 --model_config_file=<path_here> --ssl_config_file=tf_ssl.pb
The model loads well, but I get the following error:
E1205 16:16:11.240133400 7 ssl_transport_security.cc:675] Invalid cert chain file.
E1205 16:16:11.240876900 7 ssl_security_connector.cc:276] Handshaker factory creation failed with TSI_INVALID_ARGUMENT.
E1205 16:16:11.240950800 7 server_secure_chttp2.cc:81] {"created":"#1575562571.240923200","description":"Unable to create secure server with credentials of type Ssl.","file":"external/grpc/src/core/ext/transport/chttp2/server/secure/server_secure_chttp2.cc","file_line":63}
The contents of the tf_ssl.pb file are as follows:
server_key: '-----BEGIN RSA PRIVATE KEY-----MIIJKgIBAAKCAgEArq6bpXNgZt5yBoESjIuIcK9gyW+Ur5X4NJX7an93HqByhItCORLn/vHC9ACpfJARFaAPE8f0YLt8tZi+2OJ0PfQ9OQO6qQpwCgHkC2GrOCjGe9FqtdjZnBj6N19wXvXvcyNYJxVdbTUvPR10lKbCk8MaOs0ZU2KLIC3qsSrUBjsRAZXQFIMzPOVZ2UH4j1r2T66ufF0sGeW6mtDOSNZxZfGZ5/Xos1UAt7A8wDKDagRo1HJA1lPAWM9lCSVsmkeFnouu3mXyy8hNDfm3ge2mwReRXKK/4g2qyiAfaU7gopRA5uNgXLvP690cWT25xeQ6+vZLLnmkCIWzZLoqqVpClxhFfVuyxQo0LuJwMTADqUSi3e0qGCW1SmHQqOQpnGlK18JqKrqgIxk03sKaHvcrnqTGaG0yZAjypZ49Ajv23KvsoZd3zb7D904vg/Lo2zXks1KyPHNqx5e3zsmSi310WQLgNCPSuFKNKNknpkmEUn+Ev/DDMO7Xj203ta8YuGVWElmne6IpCGB3JI/Mbeu4EXQpS173mTexgSW4I5rz0/dX9Z6NapjX39v2YZwD2MsVIgdFL5vabM0BQ0AomNvM9d3PrGek0bnKR8/3ak6k07cL56N8yokow4x0HsIQlxZgVmKAJZDVZGZeowOVFqoNBrRCSg2OWLANdS3qttd88SUCAwEAAQKCAgEAiueKGWy/0c09evKUX3JtUr4DButVnrJwptBFFpC5ln8b0U4zoNLp7I8u6XzFSan+C+Y1VxN/vpQYPQdza1/X85QOQxI2EkmcgjiysGJAFu5Ftxv18Ri5IimyfunDn5+Ng08twBZ7LmZGZCDSHYrl2z4f03ZYlzgbTcF1iOB3rWS2xz3sMwOJcPkoE10kXEqG5yIO2hH1CbrmQkmcX8s2bUxLiGrBWilT4r2f8W25lkpfWeBosoXyxCxXOYiq7ZvGIycMLQmAoo9qxpw2Unk6Sv2Et9crIoSftQ8KK2Fvu5iMa42PiO5IDlTLQCOXYEd2py3G5vQPfj9jQcvQNM7zd4WSCHal1nrVcDegMmX3ZIF1sBN4S5ZMDHsWmCv4cdvj+Si0HWzVLrly5DDet2sMx31uF4tjKkPMVZlV8oxGad0d7P36GYoAkAooNwWdeF38k5atdCJw2u1aFFceI8ZC3gv6zXIW1/u7Apdfpk7k7b0KMW4SHz2WDJcsadP+JdkXSO8q7Q+4yToFrtFUswr2vaAzps1N7xko5N9hYB42ohwK5XoNPU7mezNhkS8u0Nx/0LsCaOdQwTUaUsfQQC+eYsAY5xHud/NPlFv0Jin44oKJOKXxNUtfGzu4mC+nwqGevqKzonGFQBkXkvi/fwDrNYa2k0wOFv8uHb5umSXYC4ECggEBAOT3vYwGVkef65tyDpXfb9E1IwdYYGkk0yWh0wfEX7jr6qYc8/WTHe41LjesI5w06Fo+Rkj2v/pE9dRzvCmxVu0MsoXAun0goS7laDCb6+H7B4QxSRS2jh21HQJbTkYx8CJXkKs2Nv3jfP9Yhgjc1oaEGl3Bso/k2/HdRZeZQIa+GvWUV25la3vMn1fFybTG6gSxjVBNACZB1uWmWTtqiCXauT4/Tg8IljsriWjATtE42gJ7q3MZJOr2Qm52dFhuqPdAoNQYvgHzMqyyz+D45EYAL7N5rrgBrvEm3WjuO2ZTJFhDqgU5H1bujdBONJHYMl/pyKhSvYElwCp1+XyLD7ECggEBAMNOJuNDKotihoMCXpShg/JfHQKunnb6da/h1W0FRWRUQGP3RwPWRRBs0r5MTnuIBnqG7hLZiLDozemAl38nLvAHQF5Nbvp/W8SRV0b/ysXnNQzlDLfMb3tDXJA8IJ1LcmIWNs53nQiG5oB7hSOMMr15u5wL804NnqNJECH9oHz7Ahj3XbjeZmHd1ImuQeQ6yWE3PSdVF6IdDzxz69Z9M1J9xMvP93CcUSeIfwI6qsilSXL0bjtk26phBzHTHTHILa95TrQv0xA8CrxcynXZsi2Z4nt0H/1XgMgLPn9wzmmrywCMQLrCoH8OkDj5DcXTb5GP+aVIUuq8iH7XeCN/qbUCggEBAJb7IbsGprgeJM9gu2tqZaJPZqS+SvyqMq068xvJCtG2hwk4SEoj03WzDaHaWbT0Uk7Hh7MvOlI+TNfl5Sqc7NPtLn7yIkbGUGLLFRQQjM97p24szaLh6f5+4f0e1hOFdHJAyX2Mh2CNNGxwJBoN/UvAKl6ujh9CayImpXActybijoZnZeu+5sxAlsXa/3G8RK4JokRUMggIHDtcoLSEP/iuLL52IfPZ1q53u+kd/hsKYP+IKvr/lo91CUMryvZRKgu4SxTwp8JDaqPkWR1hIa1jDBFN6L8fJQuRdChwBy0nH+0v2RoOm7LIJS05lIKjTDxgvVb5EErr6LZXCsdsL1ECggEATwys1MN0zuHcC97DpWkSXOF+fn1rCkEprTy9A9lkUs1/GncVuUnavmEtk3STN5DA/orqhZqipugzn9U6fG7Boslslj7FMoKmBBPHvab+zcddQ5DZ6vLGFKAZMRAFK2VEMMtI95yWZMMlPM/B/bdbOjGxa+GyYt9EXFbQPtHHSY7XNH+64X6y9d2xjuCHLvdUVxLin67jV+xnJFLPHAuk4DijlNLiFiRO/K9UqPRR99BewDaK/2M9PeLz5IjMgj/BrgptfqT0ytdiiQcNs1GfurFUaB+Cayolp9JVQ4PHKCIuklQyRuVLzOF6InU7y9xehg4+P1XcqcIRhTV1HPkpGQKCAQEAt24Uhm66akL9Ak/ib7DuJWl9iDRw911BYqBVNbMtcW0iZMasHtEUk+eM8g9CVfKwVHlHP/fNBL+bkPMcceJ3HYjDRgXZLjbt+16/EG3+N1xd2kPZhRufulVZ2I73PjLFfUNlKmLUXaYR0sNfOP1bmvPCupwnuM699nDQEZOJXJEPgbWvQzfUSz5K8f90eH70bB72Sl7qxSX8CZYI5ATTBUY5MacLkvpnLrs1Xvup9vFyoJ3OnDBP9OAe5e/hH3e7FYT2vV40r4KQqGmPF3MNj4eMmfTUaqcN7eNteoNmJ9YrlBNu486NFmKWkbtGPgNkKAIOv9x95r8X3R/xFObuvQ==-----END RSA PRIVATE KEY-----'
server_cert: '-----BEGIN CERTIFICATE-----MIIFRzCCAy8CAQEwDQYJKoZIhvcNAQEFBQAwaTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRIwEAYDVQQHDAlDdXBlcnRpbm8xFDASBgNVBAoMC1lvdXJDb21wYW55MRAwDgYDVQQLDAdZb3VyQXBwMREwDwYDVQQDDAhNeVJvb3RDQTAeFw0xOTExMTUxNzI5MTJaFw0yMDExMTQxNzI5MTJaMGoxCzAJBgNVBAYTAlVTMQswCQYDVQQIDAJDQTESMBAGA1UEBwwJQ3VwZXJ0aW5vMRQwEgYDVQQKDAtZb3VyQ29tcGFueTEQMA4GA1UECwwHWW91ckFwcDESMBAGA1UEAwwJbG9jYWxob3N0MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEArq6bpXNgZt5yBoESjIuIcK9gyW+Ur5X4NJX7an93HqByhItCORLn/vHC9ACpfJARFaAPE8f0YLt8tZi+2OJ0PfQ9OQO6qQpwCgHkC2GrOCjGe9FqtdjZnBj6N19wXvXvcyNYJxVdbTUvPR10lKbCk8MaOs0ZU2KLIC3qsSrUBjsRAZXQFIMzPOVZ2UH4j1r2T66ufF0sGeW6mtDOSNZxZfGZ5/Xos1UAt7A8wDKDagRo1HJA1lPAWM9lCSVsmkeFnouu3mXyy8hNDfm3ge2mwReRXKK/4g2qyiAfaU7gopRA5uNgXLvP690cWT25xeQ6+vZLLnmkCIWzZLoqqVpClxhFfVuyxQo0LuJwMTADqUSi3e0qGCW1SmHQqOQpnGlK18JqKrqgIxk03sKaHvcrnqTGaG0yZAjypZ49Ajv23KvsoZd3zb7D904vg/Lo2zXks1KyPHNqx5e3zsmSi310WQLgNCPSuFKNKNknpkmEUn+Ev/DDMO7Xj203ta8YuGVWElmne6IpCGB3JI/Mbeu4EXQpS173mTexgSW4I5rz0/dX9Z6NapjX39v2YZwD2MsVIgdFL5vabM0BQ0AomNvM9d3PrGek0bnKR8/3ak6k07cL56N8yokow4x0HsIQlxZgVmKAJZDVZGZeowOVFqoNBrRCSg2OWLANdS3qttd88SUCAwEAATANBgkqhkiG9w0BAQUFAAOCAgEAvq5lqXX5AkLssQkndB+weWjHFyUSH5wUjy35qWy5ZQL6AwFzUeGWaqhk0qJtDMn8TA5oF1LpvdG5m8dJNAam4uNGYkSOU8wNyx5TVwFEMU9PyUakjDYCEcRW0N4PuAvn2H4NSd9qnltphVuI6bKepyGaBXLlDpIUvjm+jowXNA3AcGD2YRJmJTy4iuz36QO7lzdSLzNgfRMgkIf+UsX+nnkWXpqVYYomwHgbapbau6B/HuiMR8MdQ7yTi16RFmWhsY96m51GH44xIYBc4Xz4lMSSq3VLd7Jmt/uErFegLTId3u9+8B+TjbHskXpbafUubsoE20IisY8vcnJ0epDND4IXW08lALAcjFgjiAmLtYoyu60Hw1VXk3zZ7BU8NmbRODy4RUP+AFD+vgfT/dSn5cbtJn6Gp/lM0Nr1ZzURcLar18P/HXnOI9/FfsuzCXsl9CVaDiayv7newl8/keDNsEP2DbhpKfZnpamgEnD2HxEEF+TakIuFReB/LKm0Ta0mQesAXTE3V5deoBdIjocbU72ZEsEnsl0+u5o0byU7k0tgJGMessUzNd/YNiaVqWOuwDbwJ3XX1XQveBez0QaKIjkO4atjLYIO2RK/WA1ahND8Mb4dw/xeHWhXyhjk8l3kwE1n23nYwcwBzP7seaT1Cd/IyFUZFXv2+0WmXC35g1g=-----END CERTIFICATE-----'
custom_ca: '-----BEGIN CERTIFICATE-----MIIFTjCCAzYCCQCHSSo4I8t6pTANBgkqhkiG9w0BAQsFADBpMQswCQYDVQQGEwJVUzELMAkGA1UECAwCQ0ExEjAQBgNVBAcMCUN1cGVydGlubzEUMBIGA1UECgwLWW91ckNvbXBhbnkxEDAOBgNVBAsMB1lvdXJBcHAxETAPBgNVBAMMCE15Um9vdENBMB4XDTE5MTExNTE3MjkxMloXDTIwMTExNDE3MjkxMlowaTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMRIwEAYDVQQHDAlDdXBlcnRpbm8xFDASBgNVBAoMC1lvdXJDb21wYW55MRAwDgYDVQQLDAdZb3VyQXBwMREwDwYDVQQDDAhNeVJvb3RDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAMPo3mS2heonAke575dTq8z8EayyO7XjUkC/ny00CWkE/z+A60qqm9HDCV1762FUsJwVlX1tdrMmx1WfIhLvQmTlYi+KrWIRRdOO5sSd/tN5QNkVg/Wy74csy1yPIPHRvJJdzN9HlgJ+2Za4a0GCueHYU17+nlowz5b0gpzcChe6uKeuEtfUlKh2ECjFwu+ggXFbOr0Yh5i26JGxfGTbENo/sBZBon6bvjTEsW/IuBppWLboVE+kfgOS9zODuKmfWOUfmjikzx0dZfNClyfXn9HL3uQwxgJQ9FkaNz8X186tYbQa/oLjO33EdQsVGOMjEuIf/Bz16JKite9lq4UdPVy/tEXsZ3EzEh7T0KAoqQsQSyRcrcpi9GWYMRW1VtaWirWgKIQBzhsuvPDjxjdKWpkLrc5Cr3TCiTcPrDq/Dpn+7qUg7pjzApx8EsujZEh1fmnnjtYr90pYY2y746o5QqmQtCiuNGezIsyCF2xhDOrvhJNSZ94Y0i4DUiMpT4UZEV3J+RVyvAPYXpSrLlvIATbanSWqGDrpeV5mSKl8mKi4SdCErsP9B/9Py9JoH0dg45Ap0oEE3i3cei1loDQ9Q6LSWdL13K8q+Q5Pobt7m3ZJ/FbHbfCCDrdShpUsEOzwv3E6y9q7cCB45VYee5p3YGW2KT+G+vz61sH+UeaM/d4rAgMBAAEwDQYJKoZIhvcNAQELBQADggIBAFiblbJaxNhNvCtzOTloGGAl+mJ5/BmwIrdVxPJDvEHQYqH6QOCi6FWK1qJZxkuuLLOK+7nL7pwqaIv7Gcs8rUcE/n5KLsquAmfcWwKgoa+3Tmv4ZRSu9tzC1zuHMAzdf1klrj4tAL8HCMbHe4PIZEGV0/aDrNz0Xvct6LNgYKLE0hZi+Hg3ahNILyDmPtTGMhYL0itS3I/3Y6Ae0K5n2fJMdzOttZV5LMrg698Dbj9nNdT/NCDH7X5QeaTY0q646xM5v5AoJKXQdTvsCGGEMdaU+QvAC6vpdEY+aN8OLPZ5mkAgcdlbGEhQ4jtWfaBvNDJAar7zdHHbfJwLihbzHyAqzrJ8C4SvAZVkECS6x7tL3mZrPF+N4TF986W7+ii/XOZPcfr8X2KaTV3dwDVYHe6cDAdAgw0lPrrT1acldnmDaF6tiyqdxH8NCIQv8WH3bF2PyCPrPAljB3Oh+B6muvwlGBXsHu0hZE+o8BnFak5zUDbZnLuJEZq7AP/BBYgx6iVZxtPPNuwcJQTRMTxTCq+8TE2R73AX9iQwKFy/NAkjj6ieuaxTSaSZ4VnuJO0CFy3KyTPVgB/e+H6pMOkAYti1OavPjPQCK9NYMczo6mLp2FgA/77FJhfvLFdpubKqX7MGc8D7hh9xk8iQErFXK+sl0i6lwqgDgYNJykHscj2f-----END CERTIFICATE-----'
client_verify: false
And those keys were created with the following script:
echo Generate CA key:
openssl genrsa -passout pass:1111 -des3 -out ca.key 4096
echo Generate CA certificate:
openssl req -passin pass:1111 -new -x509 -days 365 -key ca.key -out ca.crt -subj "/C=US/ST=CA/L=Cupertino/O=YourCompany/OU=YourApp/CN=MyRootCA"
echo Generate server key:
openssl genrsa -passout pass:1111 -des3 -out server.key 4096
echo Generate server signing request:
openssl req -passin pass:1111 -new -key server.key -out server.csr -subj "/C=US/ST=CA/L=Cupertino/O=YourCompany/OU=YourApp/CN=localhost"
echo Self-sign server certificate:
openssl x509 -req -passin pass:1111 -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt
echo Remove passphrase from server key:
openssl rsa -passin pass:1111 -in server.key -out server.key
I really would like to know if the problem consists in the way that I have been creating the certificates, or if it is due to an incorrect format of the tf_ssl.pb file.
Try to concatenate certs/keys lines with \n in tf_ssl.pb, e.g.:
server_cert: '-----BEGIN CERTIFICATE-----\n< CERT >\n-----END CERTIFICATE-----'
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