Hi,

I want to use DNS01 challenge for wildcard certificate. I have configured my OVH credentials with the right permissions but when calling OVH I have this error:

Status:
Presented: true
Processing: true
Reason: Waiting for DNS-01 challenge propagation: dial tcp 10.10.2.3:53: i/o timeout
State: pending

I don't understand what it means, especially this ip (10.10.2.3). I don't have any pod within cluster with this ip.

By the way, a record type TXT named "_acme-challenge.XXX.com" have been created in dns zone on OVH side.
I could confirm that the webhook client was able to talk to OVH with the right permissions.

@baarde: do you have any thoughts concerning this error ?

Thanks in advance,

Cluster: OpenShift 4
Cert Manager version: 1.6.0
Acme server (staging). https://acme-staging-v02.api.letsencrypt.org/directory
Webhook OVH version: 0.3.0

------------------------------------------------------ Webhook Client Logs ------------------------------------------------
I1102 11:05:30.778796 1 trace.go:205] Trace[477362888]: "Create" url:/apis/XXX/v1alpha1/ovh,user-agent:controller/v0.0.0 (linux/amd64) kubernetes/$Format/leader-election,audit-id:39a76cfa-73a4-4c10-970a-2b6ac6961091,client:10.64.84.31,accept:application/json, /,protocol:HTTP/2.0 (02-Nov-2021 11:05:30.023) (total time: 754ms):
Trace[477362888]: ---"Object stored in database" 754ms (11:05:30.778)
Trace[477362888]: [754.909453ms] [754.909453ms] END

Hello,

Since few minutes i have this error :
OVH API call failed: GET /domain/zone/fr/status - Error 404: "This service does not exist"

Any idea why ?

Hello !

I am trying to create a cluster issuer using your repository but I keep getting this error in the challenge event when I create a certificate.

Error presenting challenge: secrets "ovh-credentials" is forbidden: User "system:serviceaccount:cert-manager:cert-manager-webhook-ovh" cannot get resource "secrets" in API group "" in the namespace "default"

I also noticed some deprecation warnings with cert-manager v1, do you plan to update it ?

I tried to apply everything in the default workspace (like in your readme) and in the cert manager workspace. Same issue.

Thank you for your time!

My code for the cluster issuer :

apiVersion: cert-manager.io/v1
kind:       ClusterIssuer
metadata:
    name: letsencrypt
spec:
    acme:
        # The ACME server URL
        server: https://acme-v02.api.letsencrypt.org/directory
        # Email address used for ACME registration
        email:  <email@address>
        # Name of a secret used to store the ACME account private key
        privateKeySecretRef:
            name: letsencrypt
        # Enable the HTTP-01 challenge provider
        solvers:
            -   dns01:
                    webhook:
                        groupName:  '<group_name>'
                        solverName: ovh
                        config:
                            endpoint:       ovh-eu
                            applicationKey:<application_key>
                            applicationSecretRef:
                                key:  <application_secret>
                                name: ovh-credentials
                            consumerKey:    <consumer_key>

If it helps, I use sealed secrets to store the ovh-credentials secret (but it doesn't work either without)

Hello,

I am trying to use it with OCP 4.6, and it does not work.
In the pod related to ooh web hook, I get this message (See below ; the pod is in state "CrashLoopBackOff")
How to fix it please ?

Thank you

`
Error: failed to create listener: failed to listen on 0.0.0.0:443: listen tcp 0.0.0.0:443: bind: permission denied
Usage:
[flags]

Flags:
--add_dir_header If true, adds the file directory to the header of the log messages
--alsologtostderr log to standard error as well as files
--audit-log-batch-buffer-size int The size of the buffer to store events before batching and writing. Only used in batch mode. (default 10000)
--audit-log-batch-max-size int The maximum size of a batch. Only used in batch mode. (default 1)
--audit-log-batch-max-wait duration The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode.
--audit-log-batch-throttle-burst int Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode.
--audit-log-batch-throttle-enable Whether batching throttling is enabled. Only used in batch mode.
--audit-log-batch-throttle-qps float32 Maximum average number of batches per second. Only used in batch mode.
--audit-log-compress If set, the rotated log files will be compressed using gzip.
--audit-log-format string Format of saved audits. "legacy" indicates 1-line text format for each event. "json" indicates structured json format. Known formats are legacy,json. (default "json")
--audit-log-maxage int The maximum number of days to retain old audit log files based on the timestamp encoded in their filename.
--audit-log-maxbackup int The maximum number of old audit log files to retain.
--audit-log-maxsize int The maximum size in megabytes of the audit log file before it gets rotated.
--audit-log-mode string Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict. (default "blocking")
--audit-log-path string If set, all requests coming to the apiserver will be logged to this file. '-' means standard out.
--audit-log-truncate-enabled Whether event and batch truncating is enabled.
--audit-log-truncate-max-batch-size int Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size. (default 10485760)
--audit-log-truncate-max-event-size int Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded. (default 102400)
--audit-log-version string API group and version used for serializing audit events written to log. (default "audit.k8s.io/v1")
--audit-policy-file string Path to the file that defines the audit policy configuration.
--audit-webhook-batch-buffer-size int The size of the buffer to store events before batching and writing. Only used in batch mode. (default 10000)
--audit-webhook-batch-max-size int The maximum size of a batch. Only used in batch mode. (default 400)
--audit-webhook-batch-max-wait duration The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode. (default 30s)
--audit-webhook-batch-throttle-burst int Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode. (default 15)
--audit-webhook-batch-throttle-enable Whether batching throttling is enabled. Only used in batch mode. (default true)
--audit-webhook-batch-throttle-qps float32 Maximum average number of batches per second. Only used in batch mode. (default 10)
--audit-webhook-config-file string Path to a kubeconfig formatted file that defines the audit webhook configuration.
--audit-webhook-initial-backoff duration The amount of time to wait before retrying the first failed request. (default 10s)
--audit-webhook-mode string Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict. (default "batch")
--audit-webhook-truncate-enabled Whether event and batch truncating is enabled.
--audit-webhook-truncate-max-batch-size int Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size. (default 10485760)
--audit-webhook-truncate-max-event-size int Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded. (default 102400)
--audit-webhook-version string API group and version used for serializing audit events written to webhook. (default "audit.k8s.io/v1")
--authentication-kubeconfig string kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenreviews.authentication.k8s.io.
--authentication-skip-lookup If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster.
--authentication-token-webhook-cache-ttl duration The duration to cache responses from the webhook token authenticator. (default 10s)
--authentication-tolerate-lookup-failure If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous.
--authorization-always-allow-paths strings A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server. (default [/healthz,/readyz,/livez])
--authorization-kubeconfig string kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io.
--authorization-webhook-cache-authorized-ttl duration The duration to cache 'authorized' responses from the webhook authorizer. (default 10s)
--authorization-webhook-cache-unauthorized-ttl duration The duration to cache 'unauthorized' responses from the webhook authorizer. (default 10s)
--bind-address ip The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used. (default 0.0.0.0)
--cert-dir string The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "apiserver.local.config/certificates")
--client-ca-file string If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--contention-profiling Enable lock contention profiling, if profiling is enabled
--egress-selector-config-file string File with apiserver egress selector configuration.
-h, --help help for this command
--http2-max-streams-per-connection int The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default. (default 1000)
--kubeconfig string kubeconfig file pointing at the 'core' kubernetes server.
--log-flush-frequency duration Maximum number of seconds between log flushes (default 5s)
--log_backtrace_at traceLocation when logging hits line file:N, emit a stack trace (default :0)
--log_dir string If non-empty, write log files in this directory
--log_file string If non-empty, use this log file
--log_file_max_size uint Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800)
--logtostderr log to standard error instead of files (default true)
--one_output If true, only write logs to their native severity level (vs also writing to each lower severity level)
--permit-address-sharing If true, SO_REUSEADDR will be used when binding the port. This allows binding to wildcard IPs like 0.0.0.0 and specific IPs in parallel, and it avoids waiting for the kernel to release sockets in TIME_WAIT state. [default=false]
--permit-port-sharing If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false]
--profiling Enable profiling via web interface host:port/debug/pprof/ (default true)
--requestheader-allowed-names strings List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
--requestheader-client-ca-file string Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.
--requestheader-extra-headers-prefix strings List of request header prefixes to inspect. X-Remote-Extra- is suggested. (default [x-remote-extra-])
--requestheader-group-headers strings List of request headers to inspect for groups. X-Remote-Group is suggested. (default [x-remote-group])
--requestheader-username-headers strings List of request headers to inspect for usernames. X-Remote-User is common. (default [x-remote-user])
--secure-port int The port on which to serve HTTPS with authentication and authorization. If 0, don't serve HTTPS at all. (default 443)
--skip_headers If true, avoid header prefixes in the log messages
--skip_log_headers If true, avoid headers when opening log files
--stderrthreshold severity logs at or above this threshold go to stderr (default 2)
--tls-cert-file string File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.
--tls-cipher-suites strings Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.
Preferred values: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA.
--tls-min-version string Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13
--tls-private-key-file string File containing the default x509 private key matching --tls-cert-file.
--tls-sni-cert-key namedCertKey A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (default [])
--tracing-config-file string File with apiserver tracing configuration.
-v, --v Level number for the log level verbosity
--vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging

E1115 15:53:13.606408 1 cmd.go:46] cert-manager "msg"="error executing command" "error"="failed to create listener: failed to listen on 0.0.0.0:443: listen tcp 0.0.0.0:443: bind: permission denied"
`

Situation

I recently generated a certificate, the problem is that the certificate is not recognized as valid.
Here is how I create my certificate:

Certificate definition

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: altarise-registry-cert # name of the certificate
  labels:
    app.kubernetes.io/name: altarise-registry-cert # name of the certificate
    app.kubernetes.io/tier: backend
    app.kubernetes.io/managed-by: Ops
spec:
  dnsNames:
  - registry.altarise.net # name of the domain you want to validate the certificate
  issuerRef:
    name: ovh-altarise # name of the issuer you created before
    kind: Issuer
  secretName: altarise-registry-cert

Certificate events

  Type    Reason     Age    From                                       Message
  ----    ------     ----   ----                                       -------
  Normal  Issuing    5m26s  cert-manager-certificates-trigger          Existing issued Secret is not up to date for spec: [spec.commonName spec.dnsNames]
  Normal  Reused     5m26s  cert-manager-certificates-key-manager      Reusing private key stored in existing Secret resource "altarise-registry-cert"
  Normal  Requested  5m26s  cert-manager-certificates-request-manager  Created new CertificateRequest resource "altarise-registry-cert-sv2lq"
  Normal  Issuing    5m22s  cert-manager-certificates-issuing          The certificate has been successfully issued

Check of certificate using OPENSSL

CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = registry.altarise.net
verify return:1
---
Certificate chain
 0 s:CN = registry.altarise.net
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFMTCCBBmgAwIBAgISBJ3BRh0Jfr24UwVWjpCg6sdyMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjA3MjAxMDQ5NTFaFw0yMjEwMTgxMDQ5NTBaMCAxHjAcBgNVBAMT
FXJlZ2lzdHJ5LmFsdGFyaXNlLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAOHvWI8I34iFHRwZszxVHg6+asfkL4iuXD5gbnL0Vl+CmEm2iuCYSid6
55RrrfISsx5nafZKX03hN2Gln+6NXdYgH+wKtKwfXvOW3k/TzLQfkXGTlCoLh6Xb
3ZYOeNgiZk93vi6TfdKmbCILPx7p4FTxk1csN4yCjzhTlxIfcdEReYqqFCH5GK5V
SbxyfeFRXBGFa18wwdtU0TQsRHRRn+qW1bTKjm58KVZf+tOwwhQ/f1evXG+4lzVp
CK3hkM7UM/f6rIkxfgCn94Iww+4GLUo0hdPs5DhbyG2s8krfuQJclWccWg9bJGCV
0eTNgxwqu39reItOLG17SpkZxJsifD0CAwEAAaOCAlEwggJNMA4GA1UdDwEB/wQE
AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIw
ADAdBgNVHQ4EFgQUOz9H+w0S6eRu4nsQkzTrHyeVdOYwHwYDVR0jBBgwFoAUFC6z
F7dYVsuuUAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVo
dHRwOi8vcjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxl
bmNyLm9yZy8wIAYDVR0RBBkwF4IVcmVnaXN0cnkuYWx0YXJpc2UubmV0MEwGA1Ud
IARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0
dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDx
AHYAQcjKsd8iRkoQxqE6CUKHXk4xixsD6+tLx2jwkGKWBvYAAAGCG3FhxAAABAMA
RzBFAiAxNE7qyewiFC+xCOjS/29USZ92bqsn/oO2JP9tfYcxuQIhAKvCOtclt8Ja
RNmaBnByzGrCKRcXbjgOLROIjwqK+wHNAHcAKXm+8J45OSHwVnOfY6V35b5XfZxg
Cvj5TV0mXCVdx4QAAAGCG3FhzQAABAMASDBGAiEAzQUwQkP1M+8idH4bGyMYQqEo
ML+8E35tlxBOJ21piQUCIQDtQDJ4orbiLTXBjx47xWQXnKWuSE4RS2fB9xQlPJ7w
IjANBgkqhkiG9w0BAQsFAAOCAQEAdFkwiNnxS1rxW2I61aQHPBNxd4KBpzTmEPNk
LoRS7txgIBdh5U2Ecf7hxmE/nqh0Y51pBd4Q8yuJ7g5kxU48DUSiFMUB72/uUXWm
MNaMyNjzP7WRitzE9swWmqpGelhIvhdqQMgC4o+YX90yj50GsqlG+O6KBxMKKAta
QutWEiaheP+gAlhzLIZOGBxjgIsHwRU2c1ZD/naRqBzM5SZZP0njiI/b4w/znnjB
kg8fOG1Feyb/TQ9c1TzRykVEVB12XNd1R5AXdLi3NdGw0VILPWOL7ltEK1xCd1aW
VZCbFrIWZVfkx+kfOuCU+uDLmfZMOaW+Co1LsTJQ14k1x6kQ/Q==
-----END CERTIFICATE-----
subject=CN = registry.altarise.net

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4702 bytes and written 406 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 5C618DA732531FCB130CE71BDE79E1ADB9C26FBB78A3058DAAE422EF271FF71A
    Session-ID-ctx: 
    Master-Key: D3643057C1283793B6CB842559758E7F838FBC7FA1DE7BA1DF949A5E1AB354AB1E403159965B2FC62C5E26DC0A3868E4
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 21 27 64 05 33 33 c9 c2-16 5f 42 64 cd 3b 46 09   !'d.33..._Bd.;F.
    0010 - e7 a5 09 8d 8c fe 92 f6-6e af f1 a7 0b cc 59 ce   ........n.....Y.
    0020 - cd df 1a 5a 8e 85 68 99-7f da 96 4d 06 c4 38 34   ...Z..h....M..84
    0030 - 5f 4b b3 29 88 b0 31 e1-18 8f 7a 57 5b d6 f7 2b   _K.)..1...zW[..+
    0040 - 49 92 01 92 b2 90 43 eb-c8 2b 33 bc 5b d5 a1 2f   I.....C..+3.[../
    0050 - ae d4 a8 44 26 9f f3 ce-ca 13 80 f9 0e 49 6b d5   ...D&........Ik.
    0060 - 08 4e e6 11 dc 5d 52 b4-92 f9 57 03 3a f3 43 14   .N...]R...W.:.C.
    0070 - 94 f3 41 c0 04 47 3e 46-52 a3 19 26 dc 57 0e bc   ..A..G>FR..&.W..
    0080 - 75 b4 66 92 35 cc 10 a0-90 f9 cb e8 f9 e9 d3 3a   u.f.5..........:
    0090 - 60 51 2b 61 22 92 07 40-5e 5b 44 9a c3 ae a0 45   `Q+a"..@^[D....E
    00a0 - be ff 16 dc 65 e3 26 0e-09 d4 24 ec 2e d5 40 ff   ....e.&...$...@.
    00b0 - aa 1d 6c 95 1d a2 6c 6e-bd 2b 38 fa 44 a9 c6 37   ..l...ln.+8.D..7
    00c0 - 78 39 c3 d8 17 1c f7 c1-3b b7 57 c2 25 94 42 4f   x9......;.W.%.BO

    Start Time: 1658317965
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---

Curl output

curl https://192.168.10.200:443 --header "HOST: registry.altarise.net"

curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above

Hi,

I want generate my certificate with lets encrypt and OVH, I followed this guide https://dev.to/iderr/use-ovh-as-a-dns-01-provider-for-cert-manager-5hl7

Record challenge _acme-challenge.xxx.yyy.com. is created in my OVH domain zone. So OVH connection is OK
But propagation check failed in loop

cert-manager pod logs :

...
E1224 02:53:24.382561       1 sync.go:186] cert-manager/controller/challenges "msg"="propagation check failed" "error"="DNS record for \"xxx.yyy.com\" not yet propagated" "dnsName"="xxx.yyy.com" "resource_kind"="Challenge" "resource_name"="xxx-yyy-com-tls-v54tn-112196193-1530170224" "resource_namespace"="kube-system" "resource_version"="v1" "type"="DNS-01" 
E1224 02:53:34.386310       1 sync.go:186] cert-manager/controller/challenges "msg"="propagation check failed" "error"="DNS record for \"xxx.yyy.com\" not yet propagated" "dnsName"="xxx.yyy.com" "resource_kind"="Challenge" "resource_name"="xxx-yyy-com-tls-v54tn-112196193-1530170224" "resource_namespace"="kube-system" "resource_version"="v1" "type"="DNS-01" 
E1224 02:53:44.388556       1 sync.go:186] cert-manager/controller/challenges "msg"="propagation check failed" "error"="DNS record for \"xxx.yyy.com\" not yet propagated" "dnsName"="xxx.yyy.com" "resource_kind"="Challenge" "resource_name"="xxx-yyy-com-tls-v54tn-112196193-1530170224" "resource_namespace"="kube-system" "resource_version"="v1" "type"="DNS-01"
...

Loop again and again...

Any idea please 🙏 ?

Kubernetes version : v1.22.4-3+adc4115d990346
Cert Manager controller version : v1.6.1
Cert Manager webhook ovh version : 0.3.0
Letsencrypt server: https://acme-staging-v02.api.letsencrypt.org/directory (tested with production too)

rbac.authorization.k8s.io/v1beta1 is unavailable in v1.22+

Please upgrade your templates to use rbac.authorization.k8s.io/v1

Hello, i'm trying to get my ssl wildcard for a domain. It works. But with a second domain, i get this error ine the challenge :

Error presenting challenge: OVH API │
│ call failed: GET /domain/zone/mydomain/status - Error 400: "Invalid signature"

Hello and thank you for your hard work on this project.

I would like to deploy this to my cluster with the Terraform helm provider, but there is no simple way of adding this repo's helm chart and deploy it. Unless I am not aware of this chart's availability on a helm repository, publishing this chart to artifacthub.io would make things easier in that use case, and many other situations.

Hi,

I want to use DNS01 challenge for wildcard certificate. I have configured my OVH credentials with the right permissions but when calling OVH I have this error: 'Invalid Signature'.

K8s version: 1.19.2
Cert Manager version: 1.0.3
Webhook OVH version: 0.1.0

consumerKey is advised by OVH not to be disclosed. Is it safe to store it in plaintext?

a secret “consumer key“, not to be disclosed, called CK. For example:
https://support.us.ovhcloud.com/hc/en-us/articles/360018130839-First-Steps-with-the-OVHcloud-API

Maybe it could be referenced as same as applicationKey?

Hey,

I suggest to add the 'cert-manager-webhook' topic to your repo, as it helps finding it. The cert-manager documentation for webhooks links to this topic.

Best regards

👀 Fork of the project maintained here => https://github.com/aureq/cert-manager-webhook-ovh

The project is no longer maintained by the author, so a more secure and maintained fork has been created.

Hi,

after migrating to microk8s 1.22.0 cert-manager-webhook-ovh fails and the container is crash looping:

E0829 09:03:06.143077       1 webhook.go:196] Failed to make webhook authorizer request: the server could not find the requested resource
E0829 09:03:06.143182       1 errors.go:77] the server could not find the requested resource
E0829 09:03:06.150878       1 webhook.go:196] Failed to make webhook authorizer request: the server could not find the requested resource
E0829 09:03:06.150949       1 errors.go:77] the server could not find the requested resource

I already updated cert-manager to version 1.53 to be compatible with k8s 1.22, but that didn't fix the issue.

I had no issue with k8s < 1.22.

BR
Markus

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

My kubernetes cluster is hosted in a restrictive network that requires using a HTTP proxy in order to access the internet. Currently cert-manager-webhook-ovh doesn't offer any support to specify a proxy in any way when using a Helm Chart.

Please consider implementing this as suggested in PR #17

Affected area/feature

• Deployment
• Environment variables