Using wildcard certificates with IBM Cloud apps

You may remember our previous post about securing custom domains with Let’s Encrypt. It describes how to use the bluemix-letsencrypt wrapper for Cloud Foundry apps to generate and retrieve SSL certificates issued by Let’s Encrypt. Today, I am going to introduce you to another option which I am using.

Recently, Let’s Encrypt announced the support and availability of wildcard certificates. With a wildcard certificate, all of my IBM Cloud apps available under a custom domain or subdomain are covered (and secured). Let’s take a look at what I did to secure Cloud Foundry apps and container apps on the IBM Cloud Kubernetes Service.

Wildcard certificates from Let’s Encrypt

We’re going to begin with Let’s Encrypt, a free, automated, and open Certificate Authority (CA). To enable HTTPS for a website (i.e., to enable secure, encrypted network communication), a certificate is needed. Let’s Encrypt is a provider (CA) for such certificates. The Electronic Frontier Foundation has created a tool—certbot—to easily obtain certificates from Let’s Encrypt:

>> git clone https://github.com/certbot/certbot
>> cd certbot
>> ./certbot-auto certonly –manual –preferred-challenges dns –server https://acme-v02.api.letsencrypt.org/directory –email domains@4loeser.net –domains *.apps.4loeser.net –no-bootstrap

With the above commands, I first fetched the certbot code and changed into the new directory. I then invoked the certbot tool to guide me through the process of obtaining a certificate for *.apps.4loeser.net. Because it includes an asterisk (*), a wildcard certificate is issued.

Wildcard certificates require a so-called DNS challenge (–preferred-challenges dns) (i.e., I have to configure the DNS server to prove that I control that domain). The certbot prompted me to configure a specific text (seen below) as a DNS TXT record for _acme-challenge.apps.4loeser.net.

DNS TXT Challenge

Once the record was in and I had verified it with the following command, I could proceed. The certbot tool then created and obtained the certificate, a private key, and more.

>> nslookup  -type=TXT _acme-challenge.apps.4loeser.net

Secure custom domains: Cloud Foundry

I’m not going to show you how to use the UI to create so-called custom domains for your Cloud Foundryapps in IBM Cloud. I could have also utilized the CLI to manage custom domains and certificates. Having a custom domain means that instead of accessing the app at mygreatapp.mybluemix.net, the app is reachable at myevengreaterapp.example.com. To get there, you would make your domain name known to IBM Cloud by following the instructions.

In my case, I first created a new subdomain, apps, for 4loeser.net at my domain registrar. Then, I pointed the CNAME record to “secure.eu-de.bluemix.net.” Lastly, I added apps.4loeser.net as a domain to IBM Cloud to serve apps hosted in Germany:

Custom domain added

As you can see, there is the Upload option for the SSL certificate. I clicked that link and uploaded the certificate and private key to the IBM Cloud domain management. When that was completed, the “Upload” option disappeared and a nice lock appeared. My custom domain is secure(d) now. To test it, I navigated in the IBM Cloud console to one of my apps, changed to its route configuration, and added a new route based on the custom domain. Visiting that URI, I could verify that the SSL certficate for HTTPS was issued by Let’s Encrypt.

Secured custom domain

Secure custom domains: Kubernetes

Once you have mastered Cloud Foundry apps, you’ll find that securing apps deployed as containers to the Kubernetes (K8S) service is a very similar process. First, I needed a Kubernetes cluster that I could secure. Once done, I could retrieve the cluster information, including the Ingress Subdomain, for that cluster:

>> ibmcloud cs cluster-get henriks-cluster

...<br>
 Master Location:        Frankfurt  <br>
 Ingress Subdomain:      henriks-cluster.eu-de.containers.appdomain.cloud  <br>
 Ingress Secret:         thesecretishere  <br>
 Workers:                2  <br>
 Worker Zones:           fra02  <br>
 ...

I needed that information to create a CNAME record. The CNAME record points the subdomain of my domain to the cluster Ingress Subdomain. Thus, all DNS requests for that subdomain are resolved by the nameserver of the IBM Cloud Kubernetes Service and the deployed apps are found. Assuming that I am already connected to the K8S cluster, I could create a TLS secret by providing the certificate and private key in PEM format:

>> kubectl create secret tls henriks-k8s-cluster-secret –cert=/home/hloeser/certs/cs.example.com/cert1.pem –key=/home/hloeser/certs/cs.example.com/privkey1.pem

I then created a YAML file with the Ingress configuration. Here is the content, which is similar to what is documented in the IBM Cloud docs:

apiVersion: extensions/v1beta1<br>
kind: Ingress<br>
metadata:<br>
  name: ingress-for-henriks-domain<br>
spec:<br>
  tls:<br>
  - secretName: henriks-k8s-cluster-secret<br>
    hosts:<br>
    - hl.cs.example.com<br>
    - hldjango.cs.example.com<br>
  rules:<br>
  - host: hl.cs.example.com<br>
     http:<br>
      paths:<br>
      - path: /<br>
        backend:<br>
          serviceName: hldjango-service<br>
          servicePort: 3000<br>
  - host: hldjango.cs.example.com<br>
     http:<br>
      paths:<br>
      - path: /<br>
        backend:<br>
          serviceName: hldjango-service<br>
          servicePort: 3000

The secret, which we created above, is referenced and used for two hosts: “hl” and “hldjango.” Thereafter, the two hosts are defined. For the sake of simplicity, both hosts use the same Django starter ap: “hldjango-service.” All that is left is to apply the configuration to the cluster; “ingress-cs-example-tls.yml” is the configuration file.

>> kubectl apply -f ingress-cs-example-tls.yml

My Python Django app is then accessible via https://hl.cs.example.com and https://hldjango.cs.example.com, each time presenting a valid certificate issued by Let’s Encrypt.

Conclusions

With these instructions, it is fairly straightforward and simple to configure and secure custom domains on IBM Cloud. Create and upload SSL certificates for the custom domains, then apply them to the apps and their routes. Let’s Encrypt provides (free) wildcard certificates that make securing custom domains on IBM Cloud even simpler. And, if you want, use the IBM Cloud Certificate Manager to keep your certificates in one place and get notified before they expire.

Related links

• Blog: Securing custom domains with Let’s Encrypt

• Blog: Introducing IBM Cloud Certificate Manager – Manage SSL/TLS Certificates for your apps

• Blog: Custom Domains and SSL Certificates on IBM Cloud Functions

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.