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.