Create Your Own Self-Signed Trusted TLS SAN Certificates

TLS SAN v3 openssl

Encryption is critical to safeguarding credentials and communication for client/server applications that use exposed service ports for functions such as APIs.

Even in a Dev/Test environment, it’s advisable to protect these endpoints with encryption. Purchasing third-party certificates can be expensive and a time-consuming process to maintain certificates across lab environments or temporary deployments, such as virtualized environments like VMware or KVM or containerized workloads on Docker or Kubernetes.

To increase the security posture of the application it’s also advisable to disable any verification bypass options for client’s API requests generated through curl, wget, Python requests or SOAP clients.

It’s typical to use the ‘-k’ option with curl to ignore any TLS issues, or to set ‘verify=False’ for Python requests for GET or POST requests to bypass verification.

To overcome the need to lower security practices to successfully connect to encrypted endpoints you can use the openSSL x509 V3 extensions to ensure end-to-end trust, even for your self-signed public key infrastructure (PKI).

The V3 extensions allow for Subject Alternate Names (SAN) to be included in the certificates which can allow you to connect using any of the arbitrary names or IP addresses assigned to your application.

By adding your self-signed Root CA certificate to the application, VMs, containers and host, you can connect to the endpoints by name or IP with the configured trust intact. In instances where your client can’t connect with a lower security standard, the self-signed SAN certificates will provide the necessary end-to-end encryption.

Trusted end-to-end encryption will mitigate against man-in-the-middle (MITM) attacks and using self-signed certificates can save on costs and provides flexibility for using all types of clients for development, testing, bench-marking, automation, etc.

Update the ssl conf file with the V3 and SAN info


openssl genrsa -out sampleRootCA.key.pem 2048
openssl req -new -x509 -extensions v3_ca -days 3650 \
-key sampleRootCA.key.pem -sha256 \
-out sampleRootCA.crt.pem -config sslsample.cnf

openssl genrsa -out sampleServer.key.pem 2048
openssl req -extensions v3_req -sha256 -new \
-key sampleServer.key.pem -out sampleServer.csr -config sslsample.cnf

openssl x509 -req -extensions v3_req -days 3650 -sha256 \
-in sampleServer.csr -CA sampleRootCA.crt.pem \
-CAkey sampleRootCA.key.pem -CAcreateserial \
-out sampleServer.crt.pem -extfile sslsample.cnf

openssl genrsa -out sampleClientDb.key.pem 2048
openssl req -extensions v3_req -sha256 -new -key sampleClientDb.key.pem \
-out sampleClientDb.csr -config sslsample.cnf

openssl x509 -req -extensions v3_req -days 1095 -sha256 \
-in sampleClientDb.csr -CA sampleRootCA.crt.pem \
-CAkey sampleRootCA.key.pem -CAcreateserial \
-out sampleClientDb.crt.pem -extfile sslsample.cnf

openssl verify -verbose -CAfile sampleRootCA.crt.pem sampleServer.crt.pem sampleClientDb.crt.pem

Once your application is configured to use the appropriate server and/or client certificates and keys, the self-signed Root CA can be added to your browser trust store to avoid annoying pop-ups about trust issues.

Set your clients to use the proper Root CA and avoid any issues or warnings with end-to-end trust.

Related articles

Limit the Exposure of Your ELK Stack Superuser Credentials

Issue Overview The Elastic Stack X-Pack module combines RBAC defined within Elasticsearch to provide authentication and authorization to the Kibana GUI for visualizing data. The relationship between the two products leads to a chicken/egg scenario […]

Learn More

What You Need to Know About Identifying, Managing & Preventing VM Sprawl

Learn how these “infrastructure vampires” can be negatively affecting your business – and what you can do to avoid it in the future. The term “VM sprawl” refers to the uncontrolled growth of virtual machines […]

Learn More

Outbound Many to One F5 SSL Proxy

Our requirement is that any server that will either initiate or terminate an SSL request must have a unique SSL issued by a third-party. That means we would need to buy an SSL certificate from […]

Learn More