To make a HTTP challenge work, you’ll need a couple pre-requisites:
Obviously by doing this, you are exposing your ingress controller to the wide web. This is not inherently dangerous if you are using IP whitelisting. It is still less secure than not exposing your services publicly.
In this article, we will:
A HTTP Challenge is where you say to let’s encrypt “Hey, I have a web service running on this specific subdomain.” And let’s encrypt says “Oh yeah? Well can I access you on that domain? Stick this key there to prove it”. Let’s Encrypt then looks for that key on your webserver, and if it finds it, gives you a valid certificate.
That’s great, and it works well. But there are drawbacks. Many consumer grade ISPs won’t give you a public IP address, or allow you to host on ports 80 or 443. You also have to forward ports to your Rancher Host. You may have been planning to do that anyway, but it’s a security concern if not. You also have to generate a new certificate for every subdomain/service you want to expose (luckily Rancher will automate that for you).
However if you can’t use the DNS challenge for whatever reason then you’re going to want to use HTTP challenges instead.
Rancher does not have fillable forms for cert-manager based instructions. Instead, we will fall back to the default way of applying settings: Kubernetes Manifests!
Different providers have different structures for Kubernetes Manifests. You can read the documentation for cert-manager manifests on their documentation.
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-staging spec: acme: server: https://acme-staging-v02.api.letsencrypt.org/directory email: firstname.lastname@example.org privateKeySecretRef: name: letsencrypt-staging solvers: - http01: ingress: class: nginx
Once you have done that, you can clear your namespace filters, and find the status of our manifest in more resources→cert-manager→ClusterIssuers. You should see a registered status for your issuer:
apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: helloworld-mydomain-com-au-staging namespace: homelab spec: secretName: helloworld-mydomain-com-au-staging issuerRef: name: letsencrypt-staging kind: ClusterIssuer dnsNames: - helloworld.mydomain.com.au
if you do not get active for your certificate, you can investigate what went wrong by looking up certificaterequests on the side panel.
Once your ingress is saved with the new certificate, you can check if your certificate is issued by the staging authority correctly!
We now have successfully generated an automatically renewing cert for
helloworld.gurucomputing.com.au. If you wish, you can also go delete the staging certificate from certficates, the staging issuer from issuers, and the staging secret from secrets. For other subdomains we just have to clone the certificate we have already created, rename it, and let cert-manager do the rest!
We can also create a valid certificate for our rancher installation. However the process is a bit different (as rancher will immediately overwrite any certificate we manually change it to)
ingress: tls: source: secret extraAnnotations: nginx.ingress.kubernetes.io/whitelist-source-range: "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
The extraAnnotations section is optional, but useful if you want to restrict who can access your rancher web interface. You may even want to lock down the interface to a smaller subnet.
apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: kub01-mydomain-com-au-production namespace: cattle-system spec: secretName: tls-rancher-ingress issuerRef: name: letsencrypt-production kind: ClusterIssuer dnsNames: - kub01.mydomain.com.au
Finally under storage→secrets, delete the existing tls-rancher-ingress secret to regenerate a lets encrypt version:
As a side benefit, you have also added additional security measures for accessing your rancher web interface via the IP whitelist!