A Complete Guide to Securely Connecting Traefik v2 and Ruby Using Mutual TLS
How to use TLS, client authentication, and CA certificates in Traefik v2 and Ruby
Create a private key and request a certificate for your Traefik v2 server
Before you can teach your server to speak TLS, you will need a certificate issued by a trusted certificate authority (CA). If your organization already runs its own CA and you have a private key and certificate for your Traefik v2 server, along with your CA's root certificate, you can skip to the next step.
To request a certificate from your CA using the step CLI, bootstrap your CA with step ca bootstrap and run the following command (sub the server name for the actual name / DNS name of your Traefik v2 server).
$ step ca certificate "myserver.internal.net" server.crt server.keyYour certificate and private key will be saved in server.crt and server.key respectively.
Request a copy of your CA root certificate, which will be used to make sure each application can trust certificates presented by other applications.
$ step ca root ca.crtYour certificate will be saved in ca.crt.
Configure Traefik v2 to authenticate itself with its TLS certificate
We now want to instruct our Traefik v2 server to identify itself using the certificate issued in the last step and to force clients to connect over TLS.
In the dynamic configuration of Traefik specify the locations of the server's certificate and private key. The certificates will be automatically used when the domain in SNI requests matches the certificate domains.
This configuration applies to manually configured certificates. For automatic certificate renewal, check the section below.
## Dynamic configuration
[[tls.certificates]]
certFile = "server.crt"
keyFile = "server.key"Traefik automatically selects the right certificates when the domain in SNI requests matches the certificate domains. To have one of the certificates be the default certificate - instead of the generated Traefik default certificate - for requests which don't match any certificate configured, you need to configure the default tls.stores.
## Dynamic configuration
[tls.stores]
[tls.stores.default]
[tls.stores.default.defaultCertificate]
certFile = "server.crt"
keyFile = "server.key"Configure Traefik v2 to require clients to authenticate with a certificate issued by your CA
To tell Traefik v2 to use mutual TLS and not just one-way TLS, we must instruct it to require client authentication to ensure clients present a certificate from our CA when they connect.
Add or configure an existing TLS option to specify the location of your CA root certificate to use for authenticating client certificates.
## Dynamic configuration
[tls.options]
[tls.options.mytlsoptions]
[tls.options.mytlsoptions.clientAuth]
caFiles = ["ca.crt"]
clientAuthType = "RequireAndVerifyClientCert"Then, when you add routers to your dynamic configuration for HTTPS traffic, you need to set tls and tls.options to enable client authentication:
## Dynamic configuration
[http]
[http.routers]
[http.routers.router1]
...
[http.routers.router1.tls]
options = "mytlsoptions"That's it! Traefik v2 should now be able to receive TLS connections from clients who authenticate themselves using a certificate issued by your trusted CA.
Create a private key and request a certificate for your Ruby client
Request a new certificate from your CA to represent your Ruby client.
$ step ca certificate "myuser" client.crt client.keyYour certificate and private key will be saved in client.crt and client.key respectively.
Make a request from Ruby using mutual TLS
Now, we need only to configure our Ruby client to make authenticated requests using our certificate and private key. The CA root certificate will be used to verify that the client can trust the certificate presented by the server.
Pass your certificate, private key, and root CA certificate to Net::HTTP to authenticate your request over TLS.
For additional security, step certificates are signed by an intermediate CA by default rather than the root CA. The intermediate certificate is bundled into your client.crt file. Ruby does not offer any mechanism to automatically load bundled certificates, so we will need to parse the individual certificates out of client.crt ourselves.
Further, Net::HTTP has an outstanding bug that excludes the extra_chain_cert parameter, which needs to be passed to OpenSSL to handle our intermediate CA certificate. We'll patch Net::HTTP to make that attribute available.
require 'openssl'
require 'net/http'
# patch Net::HTTP to support extra_chain_cert
class Net::HTTP
SSL_IVNAMES << :@extra_chain_cert unless SSL_IVNAMES.include?(:@extra_chain_cert)
SSL_ATTRIBUTES << :extra_chain_cert unless SSL_ATTRIBUTES.include?(:extra_chain_cert)
attr_accessor :extra_chain_cert
end
# ...
# parse the client certificate and intermediate CA certificate from client.crt
bundle = File.read('client.crt')
bundle_certs = bundle.scan(/-----BEGIN CERTIFICATE-----(?:.|\n)+?-----END CERTIFICATE-----/)
client_cert = OpenSSL::X509::Certificate.new(bundle_certs[0])
intermediate_cert = OpenSSL::X509::Certificate.new(bundle_certs[1])
options = {
use_ssl: true,
verify_mode: OpenSSL::SSL::VERIFY_PEER,
cert: client_cert,
extra_chain_cert: [intermediate_cert],
key: OpenSSL::PKey::EC.new(File.read('client.key')),
ca_file: 'ca.crt'
}
http = Net::HTTP.start('myserver.internal.net', 443, options)
response = http.request Net::HTTP::Get.new '/'
# do something with response...
# ...Automate certificate renewal
By default, step-ca issues certificates with a 24 hour expiration. Short-lived certificates have many benefits but also require that you renew your certificates each day before they expire. How you renew certificates is often dependent on how you deploy your application. See the step-ca certificate lifecycle management docs for more information.
All documentation content from the Hello mTLS project is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0).
Subscribe to updates
Unsubscribe anytime. See our privacy policy.
© 2024 Smallstep Labs, Inc. All rights reserved.