Contour: Update Cert-Manager Guide

[stevesloka]

Now that CertManager is v1.0 🎉 we should update the guide around how to deploy/use cert manager with Contour.

[hargrave81]

Is there some guidance at all on how to get it working, I've been banging at this for a couple weeks now and still have not been able to get the contour to "listen" to 443, which appears to effectively break the let's encrypt cert manager from ever getting my cert.

Spec:
  Dns Names:
    imgdelivered.com
    www.imgdelivered.com
  Issuer Ref:
    Group:      cert-manager.io
    Kind:       ClusterIssuer
    Name:       letsencrypt-staging
  Secret Name:  imghomepage-cert
Status:
  Conditions:
    Last Transition Time:        2020-09-06T23:59:40Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      True
    Type:                        Issuing
    Last Transition Time:        2020-09-06T23:59:40Z
    Message:                     Issuing certificate as Secret does not exist
    Reason:                      DoesNotExist
    Status:                      False
    Type:                        Ready
  Next Private Key Secret Name:  imghomepage-cert-k4grs
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    31m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  31m   cert-manager  Stored new private key in temporary Secret resource "imghomepage-cert-k4grs"
  Normal  Requested  31m   cert-manager  Created new CertificateRequest resource "imghomepage-cert-s4n2b"

I've tried several iterations of the ingress controller to get it to "go". I've tried different versions of the cert-manager as well.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: homepage
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-staging    
    # kubernetes.io/ingress.class: contour      
    certmanager.k8s.io/acme-challenge-type: http01
  labels:
    app: homepage
spec:
  tls:
  - hosts:
    - imgdelivered.com
    - www.imgdelivered.com
    secretName: imghomepage-cert

[youngnick]

Hi @hargrave81, it does look like the let's encrypt challenge is failing.

I'm not sure how cert-manager determines the CN and the SANs when there are multiple names in the Ingress record, I would check that by testing with just one name first.

I'm not sure what you mean by you haven't been able to get Contour to listen to 443 - in our example deployment, Envoy listens on 443, and should serve traffic. Contour runs on 8001 in order to have Envoy connect to it to be configured. Traffic must arrive at Envoy's port 443 somehow to be routed into the cluster. By default cert-manager will create a small deployment that answers the HTTP01 challenge from Let's Encrypt for you, and add an additional Ingress into your cluster to accomplish that.

Can you access a test app with HTTP only? That will verify that Contour and Envoy are working correctly, and check that there's no other issues with your install.

Please also feel free to contact us on #contour on the Kubernetes slack.

[hargrave81]

I'll try just one name, my services all listen on port 80 fine, and as soon as I do the redirect to TLS annotation the service goes belly up, as 443 doesn't respond. When I run a port scanner it says that 443 is not being listened to.

[youngnick]

Contour will only open port 443 when there is a valid HTTPS config from some source. Cert-manager should be making its own HTTP Ingress object to answer the HTTP01 challenge, which should allow the secret to be present for your Ingress, which will make that Ingress valid, which will result in port 443 being open.

In other words, until the secret contains a valid TLS certificate for the FQDN you've specified, Contour won't configure Envoy to listen on port 443.

I should also mention that these questions are addressed in the existing guide, if it's unclear, I'd be very happy to hear feedback about the guide as you've found it.

[hargrave81]

Again, thanks for pointing me toward some new ways to try and solve the problem. Once you suggested breaking down the request to a single domain, it gave me a slightly different error that lead me to another search result that ultimately helped me find the "challenge" logs. It indicated that the "kubernetes" server was unable to see itself on the WAN IP (e.g. it tried to reach out to imgdelivered.com but was never getting back to home/itself)

So after a little digging, the hairpin in my edgerouter wasn't configured correctly for "all my vlans" and so the server wasn't able to see itself as the wan IP.

After resolving this issue, the 443 port opened up.

Thanks again for your help.

[stevesloka]

@skriss are you still working on this? I struggled a bit recently to get this working with CertManager 1.0+ and finally figured out what was going on.

I use Certificate object directly and found I was missing a kind in the issuerRef.

Here are my working objects:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: steveslokadev-tls
  namespace: root-proxies
spec:
  commonName: stevesloka.dev
  dnsNames:
  - stevesloka.dev
  issuerRef:
    name: letsencrypt-prod-dns
    kind: ClusterIssuer
  secretName: steveslokadev-tls
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-dns
  namespace: root-proxies
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: <email>
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-prod
    # Enable the HTTP-01 challenge provider
    solvers:
    # An empty 'selector' means that this solver matches all domains
    - http01:
        ingress:
          class: 

[skriss]

I think I had only gotten as far as updating links and text, not actually testing anything. I'm not actively working on it.