Do we need to distribute the root certificate to client? - ssl

After running below commands to create the root certificate, server certificate and Server private key:
Step 1) Create certificate authority key(private key)
$ openssl genrsa -aes256 -out ca-key.pem 4096
Step 2) Create Certificate authority(root certificate) with the input(ca-key.pem)
$ openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem
Step 3) Create a private key for web server
$ openssl genrsa -out server-key.pem 4096
Step 4) Create Certificate signing request(CSR) by entering user identification. This will create public key in-turn.
$ openssl req -subj "/CN=dockerbuild.harebrained-apps.com" -sha256 -new -key server-key.pem -out server.csr
Step 5) Add the configuration
$ echo subjectAltName = IP:40.xx.xx.164,IP:10.0.0.4,IP:127.0.0.1,DNS:dockerbuildsys.westus.cloudapp.azure.com,DNS:dockerbuild.harebrained-apps.com > extfile.cnf
Step 6) Create server certificate
$ openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf
We deployed as shown below:
Root certificate is a self-signed certificate
Before a client performs a TLS handshake,
Do we need to manually supply ca.pem to every client? to add it in trusted list before accessing the server from a browser(or any other client)

Related

MQTT mosquitto - set up client for intermediate CA

I have created CA, intermediate CA and certificates signed by intermediate CA by these commands:
CA:
openssl req -new -newkey rsa:4096 -days 365 -extensions v3_ca -subj "/C=CZ/ST=aa/L=bb/O=company/OU=development/CN=ca/" -nodes -x509 -sha256 -set_serial 0 -keyout ca.key -out ca.crt
Intermediate CA:
openssl genrsa -out subca.key 4096
openssl req -new -key subca.key -out subca.csr
openssl x509 -req -days 365 -in subca.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out subca.crt -extfile openssl.cfg -extensions v3_ca
Server:
openssl req -newkey rsa:4096 -nodes -keyout server.key -subj "/C=CZ/ST=aa/L=bb/O=company/OU=development/CN=server/" -out server.csr
openssl x509 -req -extfile <(printf "subjectAltName=IP:177.18.0.1") -days 365 -in server.csr -CA subca.crt -CAkey subca.key -CAcreateserial -out server.crt
Client:
openssl genrsa -des3 -out client.key 4096
openssl req -new -key client.key -subj "/C=CZ/ST=aa/L=bb/O=company/OU=development/CN=client/" -out client.csr
openssl x509 -req -in client.csr -CA subca.crt -CAkey subca.key -CAcreateserial -out client.crt -days 365
When I verify server or client certificate, everything seems good.
Verify command I use:
openssl verify -verbose -CAfile <(cat subca.crt ca.crt) server.crt
I want to connect to the mosquitto with TLS/SSl support with these certificates.
Mosquitto configuration:
listener 1883
require_certificate false
allow_anonymous true
listener 8883
capath /mosquitto/config/certs/ca/
certfile /mosquitto/config/certs/server.crt
keyfile /mosquitto/config/certs/server.key
require_certificate true
allow_anonymous true
use_identity_as_username true
But when I want to connect with my client, I do not know how to set function tls_set() for intermediate CA. Can you help me to setup this function ? When I look to the official documentation https://www.eclipse.org/paho/index.php?page=clients/python/docs/index.php#option-functions
for function tls_set(), there is sentence that says:
"ca_certs = a string path to the Certificate Authority certificate files that are to be treated as trusted by this client."
But I don't know how to put more certificates there and I cannot use directory as argument.
Client code:
client = mqtt.Client(client_id='Monitoring Test',
clean_session=None,
userdata=None,
protocol=mqtt.MQTTv5,
transport='tcp')
client.on_message = on_message
client.tls_set(ca_certs="ca-chain.pem",
certfile="client.pem",
keyfile="client.key",
tls_version=ssl.PROTOCOL_TLSv1_2)
client.connect("177.18.0.1", port=8883, keepalive=60)
client.subscribe("topic", qos=2)
client.loop_forever(timeout=60)
I know how to do it for root CA and signed certificate by this CA.
You need to create a single file that contains all the CA certificates, much in the same way you used cat subca.crt ca.crt to pass in a "single" file to the openssl verify command.
So cat subca.crt ca.crt > ca-chain.crt (order is important)
And then pass the path to that file in the client.
p.s. You probably want per_listener_settings true if you are going to require different authentication options per listener and require_certificate false on the first listener is not doing anything in much the same way that allow_anonymous true for the second listener doesn't do anything useful if you are requiring a client certificate.
hardillb suggested me to use for client:
cat subca.crt ca.crt > ca-chain.crt (order is important)
When I used it only for client it still did not work, but as soon as I also used file ca-chain.crt for server, it works.
So change line capath /mosquitto/config/certs/ca/ in mosquitto configuration and use cafile /mosquitto/config/test/ca-chain.pem instead.

Using tensorflow_model_server with ssl configuration

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-----'

gRPC SSL No subject alternative names present

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

docker swarm certificate expiry

I am trying to create a docker swarm that has certificates that expire after 1 year or more. The documentation states the syntax and I tried this docker swarm init --cert-expiry 8760h0m0s
However under cat /var/lib/docker/swarm/certificates/swarm-node.crt when I decipher the certificate the validity is still 3 months. How do I make sure that validity is what I have set it to?
You can generate certificates manually using the OpenSSL tool and configure Docker daemon to use these certificates.
Generate Server Certificates
Generate CA private and public keys:
openssl genrsa -aes256 -out ca-key.pem 4096
openssl req -new -x509 -days 1000 -key ca-key.pem -sha256 -out ca.pem
Create a server key and certificate signing request (CSR):
openssl genrsa -out server-key.pem 4096
openssl req -subj "/CN=my.company.com" -sha256 -new -key server-key.pem -out server.csr
Sign the public key with CA:
echo subjectAltName = DNS:my.company.com,IP:127.0.0.1 >> extfile.cnf
echo extendedKeyUsage = serverAuth >> extfile.cnf
Generate the key:
openssl x509 -req -days 1000 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf
Generate Client Certificates
Create a client key and certificate signing request:
openssl genrsa -out key.pem 4096
openssl req -subj '/CN=client' -new -key key.pem -out client.csr
Create an extensions config file:
echo extendedKeyUsage = clientAuth >> extfile.cnf
Sign the private key:
openssl x509 -req -days 1000 -sha256 -in client.csr -CA ../server/ca.pem -CAkey ../server/ca-key.pem -CAcreateserial -out cert.pem -extfile extfile.cnf
Export cert.pem into PFX format to be added into Trusted Root Certification Authorities
openssl pkcs12 -export -in cert.pem -inkey key.pem -out cert.pfx
Configure Docker daemon with /etc/docker/daemon.json
{
"debug": false,
"tls": true,
"tlsverify": true,
"tlscacert": "/etc/docker/certificates/server/ca.pem",
"tlscert": "/etc/docker/certificates/server/server-cert.pem",
"tlskey": "/etc/docker/certificates/server/server-key.pem",
"hosts": ["tcp://0.0.0.0:2376", "unix:///var/run/docker.sock"]
}
Start Docker Service
systemctl start docker
Have a look at this article Building Jenkins Pipelines – Setting Up Docker Swarm. There's a step-by-step guide there.
Run the following commands on any of the management nodes:
docker swarm update --cert-expiry 8760h0m0s
docker swarm ca --rotate | openssl x509 -text -noout
The first one will set certificate expiry date.
The last one will actually apply changes and rotate certificates on all swarm nodes automatically. If not interested in decoding cert text output, the openssl part can be omitted.

I'd like to create SSL sertificates for my test environment

Does anyone have a handy script to generate SSL certificates such that it generates the CA certificate and the server certificate. More importantly, create it in a way that I can import the CA certificate into my trusted root list (of my windows system) so that the browser does not flag the site as untrusted.
I used the following script to do it but I am not able to persuade my browser to trust the certificate.
I'd greatly appreciate any help here.
# Generate a private key
openssl genrsa -des3 -out server.key 1024
# Generate a CSR (Certificate Signing Request)
openssl req -new -key server.key -out server.csr
# Remove Passphrase from Key
cp server.key server.key.org
openssl rsa -in server.key.org -out server.key
# Generating a Self-Signed Certificate
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Regards,
Kashyap
Your script is only generating one certificate, a self-signed certificate. Usually, the self-signed certificate is called the Root certificate. This can be used as a CA certificate, but often an intermediate CA certificate is created and signed by the Root private key. This intermediate CA certificate is then used to sign Server certificates. So you have this hierarchy:
Root -> CA -> Server
The CA and Root cert can go into the trusted certificate list. Then a browser that trusts that list will also trust any certificate signed by the CA or Root entities.
You don't have to have this hierarchy...you can use the Root certificate as the CA and skip the middle cert. You can also just use 1 self-signed certificate as the Root/Server certificate. See this article (Trusting self-signed certificates).
But assuming you do have this hierarchy, here are some OpenSSL commands to generate the necessary keys and certificates:
# 1. Create Root private key
openssl genrsa -out root.key 2048
# 2. Create self-signed Root certificate
openssl req -new -key root.key -x509 -out root.crt -days 5000 -sha256
# 3. Create CA private key
openssl genrsa -out ca.key 2048
# 4. Create CA CSR
openssl req -new -key ca.key -out ca.csr -days 5000
# 5. Sign and create CA certificate
openssl x509 -req -in ca.csr -CA root.crt -CAkey root.key -out ca.crt -set_serial 2 -days 5000 -sha256
# 6. Create Server private key
openssl genrsa -out server.key 2048
# 7. Create Server CSR
openssl req -new -key server.key -out server.csr -days 5000
# 8. Sign and create Server certificate
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -out server.crt -set_serial 3 -days 5000 -sha256
Change the key bits, # of valid days, serial numbers, and add V3 extensions as you see fit.
Also remember that different browsers have different lists that they trust. Chrome and IE use the Windows default list. Firefox has its own list.
Do you have a trusted CA certificate?
You are generating a self-signed certificate which is always considered as untrusted by browsers.