July 25, 2018 By Henrik Loeser 4 min read

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

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

Was this article helpful?
YesNo

More from Cloud

A clear path to value: Overcome challenges on your FinOps journey 

3 min read - In recent years, cloud adoption services have accelerated, with companies increasingly moving from traditional on-premises hosting to public cloud solutions. However, the rise of hybrid and multi-cloud patterns has led to challenges in optimizing value and controlling cloud expenditure, resulting in a shift from capital to operational expenses.   According to a Gartner report, cloud operational expenses are expected to surpass traditional IT spending, reflecting the ongoing transformation in expenditure patterns by 2025. FinOps is an evolving cloud financial management discipline…

IBM Power8 end of service: What are my options?

3 min read - IBM Power8® generation of IBM Power Systems was introduced ten years ago and it is now time to retire that generation. The end-of-service (EoS) support for the entire IBM Power8 server line is scheduled for this year, commencing in March 2024 and concluding in October 2024. EoS dates vary by model: 31 March 2024: maintenance expires for Power Systems S812LC, S822, S822L, 822LC, 824 and 824L. 31 May 2024: maintenance expires for Power Systems S812L, S814 and 822LC. 31 October…

24 IBM offerings winning TrustRadius 2024 Top Rated Awards

2 min read - TrustRadius is a buyer intelligence platform for business technology. Comprehensive product information, in-depth customer insights and peer conversations enable buyers to make confident decisions. “Earning a Top Rated Award means the vendor has excellent customer satisfaction and proven credibility. It’s based entirely on reviews and customer sentiment,” said Becky Susko, TrustRadius, Marketing Program Manager of Awards. Top Rated Awards have to be earned: Gain 10+ new reviews in the past 12 months Earn a trScore of 7.5 or higher from…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters