Cert-manager: self domain check failed

[tcstapas]

I have deployed ca-manager using helm stable ca-manager, The CA manager pods log is saying "self domain check" failed. Am I missing anything? The URL is public and I checked it's working fine from outside of ca pod, but within pod, wget is failing.

FYI - I have used lets encrypt v2 issuer and certificate to generate secret for ingress

Thanks!

[thebigredgeek]

Are you on GKE? I'm also having this problem

[FabioSchmidberger]

Hi, I have the same problem. @thebigredgeek I am also GKE and my cert-manager is logging the following:

E0608 09:00:53.969105 1 controller.go:186] certificates controller: Re-queuing item "namespace/secret" due to error processing: http-01 self check failed for domain "sub.mydomain.de"

I can access my service using http, how ever https does not work.
Does anyone know further debugging steps I could take?

I have the following Configuration:

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: campusbeach-tls
  namespace: web-restaurant-5043044
spec:
  secretName: campusbeach-tls
  dnsNames:
  - sub.mydomain.de
  acme:
    config:
    - http01:
        ingress: prod
        ingressClass: nginx
      domains:
      - sub.mydomain.de
  issuerRef:
    name: letsencrypt-staging

apiVersion: certmanager.k8s.io/v1alpha1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: web-restaurant-5043044
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: [email protected]
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-staging
    # Enable the HTTP-01 challenge provider
    http01: {}

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: prod
  namespace: web-restaurant-5043044
  annotations:
    kubernetes.io/ingress.global-static-ip-name: my-ip
    kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: nginx
    kubernetes.io/issuer: "letsencrypt-staging"
spec:
  rules:
  - host: sub.mydomain.de
    http:
      paths:
      - path: /*
        backend:
          serviceName: prod
          servicePort: 80
  tls:
  - hosts:
    - sub.mydomain.de
    secretName: campusbeach-tls

Describing my Certificate prints the following:

```
Name: campusbeach-tls
Namespace: web-restaurant-5043044
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"certmanager.k8s.io/v1alpha1","kind":"Certificate","metadata":{"annotations":{},"name":"campusbeach-eas-tls","namespace":"web-restauran...
API Version: certmanager.k8s.io/v1alpha1
Kind: Certificate
Metadata:
Cluster Name:
Creation Timestamp: 2018-06-07T14:40:29Z
Generation: 0
Initializers:
Resource Version: 223443
Self Link: /apis/certmanager.k8s.io/v1alpha1/namespaces/web-restaurant-5043044/certificates/campusbeach-tls
UID: b98c6c97-6a60-11e8-bba8-42010a84011a
Spec:
Acme:
Config:
Domains:
sub.mydomain.de
Http 01:
Ingress: prod
Ingress Class: nginx
Common Name:
Dns Names:
sub.mydomain.de
Issuer Ref:
Name: letsencrypt-staging
Secret Name: campusbeach-tls
Status:
Acme:
Order:
Challenges:
Authz URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz/51k8wd9-mHsdqV6OZlINqKxn3Bp8wbmW4RQwDxlAUeU
Domain: sub.mydomain.de
Http 01:
Ingress: prod
Ingress Class: nginx
Key: KEY-VALUE
Token: TOKEN-VALUE
Type: http-01
URL: https://acme-staging-v02.api.letsencrypt.org/acme/challenge/51k8wd9-mHsdqV6OZlINqKxn3Bp8wbmW4RQwDxlAUeU/133844110
Wildcard: false
URL: https://acme-staging-v02.api.letsencrypt.org/acme/order/6243441/1820784
Conditions:
Last Transition Time: 2018-06-08T09:26:11Z
Message: http-01 self check failed for domain "sub.mydomain.de"
Reason: ValidateError
Status: False
Type: Ready
Events:
````

[thebigredgeek]

@FabioSchmidberger I was actually missing something super simple... I forgot to point the domain name to the ingress IP so the acme self check was failing to verify domain ownership etc.

[FabioSchmidberger]

@thebigredgeek thanks for commenting. I use a global static ip from gcloud. and reference it in my ingress definition using kubernetes.io/ingress.global-static-ip-name: my-ip. I have my dns pointed to this ip. When opening the "my-ip" or the domain name in the browser I can reach the application (as long as I don't use https).

However when I execute kubectl get ingress prod -n web-restaurant-5043044 I get the following:

NAME      HOSTS                  ADDRESS          PORTS     AGE
prod      sub.mydomain.de   130.***.87.160   80, 443   1d

where the Ip Adress 130.*.87.160 does not match my global gcloud Ip address and therefore does not match the IP I pointed the dns to.

Is this a problem?

When entering the IP 130.*.87.160 in the browser, I don't reach my application but when entering the domain I do.

[thebigredgeek]

Make sure that ALL listed domain names on your cert are actually live and pointing to the ingress IP that cert-manager is using.

[almerico]

looks like I have something similar on GKE. Maybe something wrong with config files. Does used secret have to be created automatically ? I got secret "emailbpm-cert" not found in log.

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
# The ACME server URL
server: https://acme-v02.api.letsencrypt.org/directory
# Email address used for ACME registration
email: [email protected]
# Name of a secret used to store the ACME account private key
privateKeySecretRef:
name: letsencrypt-staging
# Enable the HTTP-01 challenge provider
http01: {}

----

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
certmanager.k8s.io/cluster-issuer: letsencrypt-staging
kubernetes.io/ingress.class: nginx

name: ui-emailbpm-ingress
namespace: jx-staging
spec:
rules:

• host: ui.emailbpm.com
  http:
  paths:
  
  
  
  • backend:
    
    serviceName: activiti-cloud-demo-ui
    
    servicePort: 80
    
    tls:
  
  
• hosts:
  
  
  
  • ui.emailbpm.com
    
    secretName: emailbpm-cert
  
  

----

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
name: emailbpm-cert
spec:
secretName: emailbpm-cert
issuerRef:
name: letsencrypt-staging
kind: ClusterIssuer
commonName: ui.emailbpm.com
dnsNames:

• ui.emailbpm.com
  acme:
  config:
  
  
  
  • http01:
    
    ingressClass: nginx
    
    domains:
    
    
    
    
    
    • ui.emailbpm.com
    
    
    
  
  

in cert-controller-manager log:

I0713 13:49:57.487850 1 controller.go:177] certificates controller: syncing item 'jx-staging/emailbpm-cert'
I0713 13:49:57.488000 1 sync.go:239] Preparing certificate jx-staging/emailbpm-cert with issuer
I0713 13:49:57.488026 1 acme.go:159] getting private key (letsencrypt-staging->tls.key) for acme issuer kube-system/letsencrypt-staging
I0713 13:49:57.488545 1 logger.go:27] Calling GetOrder
I0713 13:49:57.606826 1 logger.go:52] Calling GetAuthorization
I0713 13:49:57.668328 1 logger.go:72] Calling HTTP01ChallengeResponse
I0713 13:49:57.668389 1 prepare.go:263] Cleaning up old/expired challenges for Certificate jx-staging/emailbpm-cert
I0713 13:49:57.668425 1 logger.go:47] Calling GetChallenge
I0713 13:49:57.788468 1 ingress.go:33] Looking up Ingresses for selector certmanager.k8s.io/acme-http-domain=769590721,certmanager.k8s.io/acme-http-token=1586106308
I0713 13:49:57.788542 1 helpers.go:188] Found status change for Certificate "emailbpm-cert" condition "Ready": "False" -> "False"; setting lastTransitionTime to 2018-07-13 13:49:57.788536069 +0000 UTC m=+101014.497463189
I0713 13:49:57.788562 1 sync.go:241] Error preparing issuer for certificate jx-staging/emailbpm-cert: http-01 self check failed for domain "ui.emailbpm.com"
E0713 13:49:57.794970 1 sync.go:168] [jx-staging/emailbpm-cert] Error getting certificate 'emailbpm-cert': secret "emailbpm-cert" not found
E0713 13:49:57.795026 1 controller.go:186] certificates controller: Re-queuing item "jx-staging/emailbpm-cert" due to error processing: http-01 self check failed for domain "ui.emailbpm.com"

[munnerz]

@FabioSchmidberger it looks like you've specified both ingress and ingressClass on your Certificate resource - note that these two fields are mutually exclusive! If you are using GCE ingress, you should specify the ingress field as the name of your GCE ingress.

Please also see #606 if you are using GCE, as there have been some problems reported recently.

@tcstapas did you manage to resolve this issue? As any of the discussion above helped? 😄