Wilson Mar bio photo

Wilson Mar


Calendar YouTube Github



TLS v1.3 (Transport Layer Security), the latest successor to SSL, secures network communications with https protocol and mTLS (mutual TLS) using x.509 format certificates

US (English)   Norsk (Norwegian)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Estonian   اَلْعَرَبِيَّةُ (Egypt Arabic)   Napali   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean


NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.

Secure Data in Transit

Data in-transit is what moves between one system and another. It includes data moving between resources within an organization (such as passwords, secrets, keys), and outside services.

Protecting data in transit means ensuring a triad of conditions:

  • confidentiality (privacy of not being seen by unauthorized others eavesdropping)
  • integrity of the data (not corrupted, tampered by others)
  • availability of the data (when and where needed, despite disasters)

Reliability groups together integrity and availability.

A server can ensure that it interacts with only a known set of users (rather than anonymous users) by requiring use of mTLS (mutual TLS) on both ends of the communication – where a TLS certificate (from a CA) is installed on the sit’s clients. mTLS enables websites to choose which requesters to communicate with. A client-side TLS certificate proves that the client is known to the server. There is are additional conditions:

  • level of authentication (only those who are known have access)
  • level of authorization (access is limited to specific actions - add, list, view, change, delete, etc.)

HashiCorp Consul automates enablement of mTLS for communication between app services. Even legacy apps can use mTLS because Consul intercepts traffic as a proxy in a service mesh. Use of a proxy architecture enables Consul to enforce mTLS across clouds and platforms. Consul can create signed certificates automatically. Its approach enables rapid and comprehensive upgrade of new TLS versions and cipher suites in the future, avoiding slow massive upgrade of code in all apps. https://learn.microsoft.com/en-us/security/engineering/solving-tls1-problem

Quick response is necessary DocuSign Connect HMAC (Hash-Based Message Authentication Codes) See https://developers.docusign.com/platform/webhooks/connect/hmac/ https://www.jscape.com/blog/what-is-hmac-and-how-does-it-secure-file-transfers

Most websites today have obtained SSL (Secure Socket Layer) certificates from a CA (Certificate Authority) to use https (instead of http) protocol (through port 443) for encrypted communication with browsers. TLS is also used to wrap FTP (FTPS, not to be confused with SFTP which uses the SSH protocol), IMAP (IMAPS), POP3 (POP3S), and SMTP (SMTPS), among others.

Additionally, companies such as DocuSign also encrypt files being transferred. DocuSign uses HMAC to create a hash.

On browsers, a lock icon appears next to the URL address to indicate use of encryption. Regular http is dangerous because someone (a man in the middle) can intercept the traffic and insert malicious code before forwarding to the user’s browser. TLS (Transport Layer Security) is essentially the newer version of SSL.

The latest version, currently TLS v1.3, is used to provide the highest security. That is because cryptographic algorithms can be cracked over time. TLS 1.3 removed use of ECDHE_RSA among the three ciphers: QUIC, X25519, and AES_128_GCM. Microsoft enabled TLS 1.3 by default in 2020. The list of which browser supports TLS 1.3 is at https://caniuse.com/tls1-3

  1. Verify whether your browser and website together supports TLS 1.3 certificates:



    TLS 1.1 and TLS 1.0 should be disabled.


  2. Ensure that the website insists on use of encrypted traffic using HTTPS (over port 443) rather than insecure HTTPS (over port 80) by use of the HSTS (HTTP Strict Transport Security) policy mechanism:


    HSTS works by the server responding to client agents in HTTPS containing a response header field such as
    Strict-Transport-Security: max-age=3153600; includeSubDomains; preload
    which specifies a year of seconds the user agent should only access the server using HTTPS protocol.

    HSTS was published as RFC 6797 (on 19 November 2012) for browsers to be programmed to recognize the header and automatically upgrade to use HTTPS. See the version of each browser added the feature.

    HSTS should also work with utilities such as curl. Many websites that prefer HTTPS still listen for connections over HTTP in order to redirect the user to the HTTPS URL.

    curl --head http://github.com

    A redirect such as the following is insecure and provides an opportunity for attackers to capture information about the visitor (such as cookies from a previous secure session), or to maliciously redirect the user to a phishing site:

    HTTP/1.1 301 Moved Permanently
    Location: https://github.com/

    The HTTP protocol has been found to be vulnerable against man-in-the-middle attacks where traffic is intercepted and then forwarded.

    When HSTS is enabled, the response to:

    curl --head http://irs.gov

    would look like this:

    HTTP/1.0 301 Moved Permanently
    Location: https://irs.gov/
    Strict-Transport-Security: max-age=31536000
    Server: BigIP
    Connection: Keep-Alive
    Content-Length: 0


    curl --head http://cisa.gov
    HTTP/1.1 301 Moved Permanently
    Server: AkamaiGHost
    Content-Length: 0
    Location: https://cisa.gov/
    Cache-Control: max-age=0
    Expires: Sat, 08 Oct 2022 14:05:59 GMT
    Date: Sat, 08 Oct 2022 14:05:59 GMT
    Connection: keep-alive

    Websites may request at hstspreload.org to be added to the Preload list used by websites.

Securing Web Services

“Let’s Encrypt” provides free automated TLS certificates for all applications. Their free certificates are valid for 90 days. Paid certificates are valid for years at a time.

K8s Cert Manager

The Kubernetes Cert Manager service is useed to apply for certs and automate the renewal process. It’s fast and easy and works seemlessly on EKS.

To install it:

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager.yaml

To see what was installed:

kubectl get pods -n cert-manager

The main service watches for changes in Kubernetes and then acts to create certificate requests if needed. Test with the staging issuer:

cd cert-manager
kubectl create -f staging-issuer.yaml

For the production issuer:

kubectl create -f prod-issuer.yaml

See resources created:

kubectl get clusterissuers

Sample response:

NAME                  READY   AGE
letsencrypt-prod      True    96s
letsencrypt-staging   True    108s

Create the TLS certificate on our application to modify the ingress rule.

View changesin the ngx-ing.yaml in the same directory:

apiVersion: extensions/v1beta1
kind: Ingress
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
  name: ngx
  namespace: default
  - hosts:
    - k8s.castlerock.ai
    secretName: ngx-tls-cert
    - host: k8s.castlerock.ai
        - backend:
            serviceName: ngx
            servicePort: 80

The changes are:

  • cert-manager.io/cluster-issuer: letsencrypt-prod - tells that we want to issue TLS and the cluster issuer to use to get that certificate.
  • tls - specifies which domain we want as well as where to store the TLS secrets once obtained them from the service.

To troubleshoot, look at custom resources:

kubectl get orders
kubectl get certificates
kubectl get certificaterequests

These are the actions created when the ingress rule specifies a TLS service.

Check your domain again and see that it works with encryption.

Set Up Mutual TLS Authentication


  1. Obtain the version to ensure that the utility is working:

    openssl version
  2. To make it easier to handle different certificates for different parts of the application, have certificate to a subdomain.

  3. A subdomain constraint to your routes:

    constraints subdomain: 'admin' do
       resources :users # or ActiveAdmin.routes(self) for the ActiveAdmin gem
  4. Create a CA (Certificate Authority) to sign both the server and client certificate requests.

    Root CAs are not used to sign certificates directly.

    Root CAs are used to create trusted intermediate CAs to sign certificates.

  5. The root CA needs to be kept very secure, such as in a disconnected (air gapped) computer.

  6. Designate a folder to keep CA keys and certificates. On a Linux machine:

  7. Identify the key length of 4096 for the CA. The encryption algorithms 3DES or AES with a 256 bit key length are acceptable here and a strong password is desirable. (SHA1 shouldn’t be used anymore)

  8. Create a new private key with a password for the CA:

    openssl genrsa -aes256 -out ca/ca.key 4096 chmod 400 ca/ca.key
  9. Create the root CA certificate with a validity of two years using the SHA256 hash algorithm :

    openssl req -new -x509 -sha256 -days 730 -key ca/ca.key -out ca/ca.crt

    Leave all attribute fields blank by entering .. Only the CommonName will be 42CA to identify the certificate.

    chmod 444 ca/ca.crt
  10. Verify the root certificate to check the validity (2 years).

    openssl x509 -noout -text -in ca/ca.crt

    The Issuer and Subject are both 42CA because this is a root certificate, which are always self-signed.

  11. Create a CSR (Certificate Signing Request) from the server. The request is to create a certificate for a specific domain name. Usually, the CA and the certificate requester are two different companies who don’t want to share their private keys. That’s why this middle step is needed.

    First, we’ll create a private key for the server and then the CSR. Use a 2048 bit keys because the key is only valid for a year, and 4096 bits would slow down the TLS handshake.

    The -aes256 option is omitted so a password doesn’t have to be entered every time the web server is started.

    openssl genrsa -out server/client-ssl.bauland42.com.key 2048
    chmod 400 server/client-ssl.bauland42.com.key
    openssl req -new -key server/client-ssl.bauland42.com.key -sha256 -out server/client-ssl.bauland42.com.csr

    A dot is entered for each CSR detail. But the Common Name has to be the server’s fully qualified domain name. For example, “client-ssl.bauland42.com”.

  12. Use the root CA to sign the CSR (for a year). You’ll be prompted to enter the root CA’s password.

    openssl x509 -req -days 365 -sha256 \
    -in server/client-ssl.bauland42.com.csr -CA ca/ca.crt \
    -CAkey ca/ca.key -set_serial 1 -out server/client-ssl.bauland42.com.crt
    chmod 444 server/client-ssl.bauland42.com.crt
  13. Verify the Validity, the Issuer (42CA), and the Subject (client-ssl.bauland42.com):

    openssl x509 -noout -text -in server/client-ssl.bauland42.com.crt 
  14. Verify the chain of trust. Although, it’s not really a chain – the root CA signed the server certificate directly.

    openssl verify -CAfile ca/ca.crt server/client-ssl.bauland42.com.crt
    server/client-ssl.bauland42.com.crt: OK
  15. It’s best if the user created the client’s CSR so that the server wouldn’t see the user’s private key. To generate the client certificate:

    openssl genrsa -out client/heiko.key 2048
    openssl req -new -key client/heiko.key -out client/heiko.csr
    openssl x509 -req -days 365 -sha256 -in client/heiko.csr \
       -CA ca/ca.crt -CAkey ca/ca.key -set_serial 2 -out client/heiko.crt

    The server would sign the CSR and return the certificate to the user.

    We’ll use the serial number 2 for this certificate.

  16. Make use of the client certificates.



More on DevSecOps

This is one of a series on DevSecOps:

  1. DevOps_2.0
  2. ci-cd (Continuous Integration and Continuous Delivery)
  3. User Stories for DevOps
  4. Enterprise Software)

  5. Git and GitHub vs File Archival
  6. Git Commands and Statuses
  7. Git Commit, Tag, Push
  8. Git Utilities
  9. Data Security GitHub
  10. GitHub API
  11. TFS vs. GitHub

  12. Choices for DevOps Technologies
  13. Pulumi Infrastructure as Code (IaC)
  14. Java DevOps Workflow
  15. Okta for SSO & MFA

  16. AWS DevOps (CodeCommit, CodePipeline, CodeDeploy)
  17. AWS server deployment options
  18. AWS Load Balancers

  19. Cloud services comparisons (across vendors)
  20. Cloud regions (across vendors)
  21. AWS Virtual Private Cloud

  22. Azure Cloud Onramp (Subscriptions, Portal GUI, CLI)
  23. Azure Certifications
  24. Azure Cloud

  25. Azure Cloud Powershell
  26. Bash Windows using Microsoft’s WSL (Windows Subsystem for Linux)
  27. Azure KSQL (Kusto Query Language) for Azure Monitor, etc.

  28. Azure Networking
  29. Azure Storage
  30. Azure Compute
  31. Azure Monitoring

  32. Digital Ocean
  33. Cloud Foundry

  34. Packer automation to build Vagrant images
  35. Terraform multi-cloud provisioning automation
  36. Hashicorp Vault and Consul to generate and hold secrets

  37. Powershell Ecosystem
  38. Powershell on MacOS
  39. Powershell Desired System Configuration

  40. Jenkins Server Setup
  41. Jenkins Plug-ins
  42. Jenkins Freestyle jobs
  43. Jenkins2 Pipeline jobs using Groovy code in Jenkinsfile

  44. Docker (Glossary, Ecosystem, Certification)
  45. Make Makefile for Docker
  46. Docker Setup and run Bash shell script
  47. Bash coding
  48. Docker Setup
  49. Dockerize apps
  50. Docker Registry

  51. Maven on MacOSX

  52. Ansible
  53. Kubernetes Operators
  54. OPA (Open Policy Agent) in Rego language

  55. MySQL Setup

  56. Threat Modeling
  57. SonarQube & SonarSource static code scan

  58. API Management Microsoft
  59. API Management Amazon

  60. Scenarios for load
  61. Chaos Engineering