📋 Recommended Actions
✅ No Immediate Action Required
No immediate action required. Review updates to better support your users, especially around ACME HTTP01 challenge handling and Ingress-Nginx compatibility.
📝 Summary
cert-manager v1.18.1 delivers critical enhancements for ACME HTTP01 challenges and improved compatibility with Ingress-Nginx. This release introduces the ACMEHTTP01IngressPathTypeExact feature gate, now Beta and enabled by default, which switches the Ingress pathType to Exact for heightened security. This prevents misinterpretations of challenge paths and aligns with standard Ingress behaviors. A significant dependency upgrade bumps Ingress-Nginx to v1.12.3, coupled with a vital configuration change that disables strict-validate-path-type to prevent HTTP01 challenge failures caused by a bug in newer Ingress-Nginx versions. Furthermore, the ACME authorization timeout is extended from 20 seconds to 2 minutes, significantly improving reliability for challenges against slower ACME servers or under poor network conditions. The DefaultPrivateKeyRotationPolicyAlways feature gate is also promoted to Beta, ensuring consistent private key rotation. Review these changes to ensure optimal ACME challenge resolution and cluster stability.
🔒 Enhanced ACME HTTP01 Challenge Security with Exact PathType
To bolster the security and predictability of ACME HTTP01 challenges, cert-manager v1.18.1 introduces and defaults the ACMEHTTP01IngressPathTypeExact feature gate to true. This crucial update ensures that the Ingress pathType for ACME HTTP01 challenges is set to Exact, moving away from the more ambiguous ImplementationSpecific. The intent behind this change is to prevent any misinterpretation of challenge paths by various Ingress controllers, guaranteeing that your .well-known/acme-challenge URLs are matched precisely. This enhanced precision is particularly beneficial for compatibility with standards-compliant Ingress controllers like Cilium, reducing potential vulnerabilities where a less strict path matching might expose unintended resources. Users of ingress-nginx may need to be aware, though cert-manager now directly addresses a compatibility bug as detailed in the next section.
When ACMEHTTP01IngressPathTypeExact is enabled (which is the default in this release), cert-manager will now generate Ingress resources for HTTP01 challenges with PathType: Exact. If you encounter compatibility issues with specific Ingress controllers that do not handle PathTypeExact as expected, you can disable this feature gate by setting featureGates.ACMEHTTP01IngressPathTypeExact: false in your cert-manager controller configuration. This will revert the pathType to ImplementationSpecific.
apiVersion: controller.config.cert-manager.io/v1alpha1
kind: ControllerConfiguration
featureGates:
ACMEHTTP01IngressPathTypeExact: false
Source:
internal/controller/feature/features.go(172-212)pkg/issuer/acme/http/ingress.go(377-387)pkg/issuer/acme/http/ingress_test.go(72-132)deploy/charts/cert-manager/values.yaml(251-252)
🚀 Ingress-Nginx Upgrade and HTTP01 Challenge Reliability
This release significantly improves cert-manager’s compatibility and reliability when working with ingress-nginx by upgrading its internal testing and e2e setup to Ingress-Nginx controller v1.12.3 (and Helm chart v4.12.3). Crucially, this upgrade includes a necessary configuration adjustment to work around a known issue in ingress-nginx versions 1.8.0 and above. Specifically, the strict-validate-path-type option, which is enabled by default in ingress-nginx >= 1.12.0, incorrectly disallows dots in path values, breaking ACME HTTP01 challenges. cert-manager now explicitly disables this validation, ensuring seamless ACME challenge resolution for users running newer ingress-nginx versions. Additionally, the ingress-nginx admission webhook is now enabled in the testing setup, reflecting common deployment patterns.
The e2e-setup.mk Makefile now reflects these changes by updating the ingress-nginx image and Helm chart versions, and adding the --set-string controller.config.strict-validate-path-type=false flag to the Helm installation. This ensures that the dot character in the /.well-known/acme-challenge/<TOKEN> path is not incorrectly rejected by ingress-nginx.
e2e-setup-ingressnginx: $(call image-tar,ingressnginx) load-$(call image-tar,ingressnginx) | $(NEEDS_HELM)
@$(eval TAG=$(shell tar xfO $< manifest.json | jq '.[0].RepoTags[0]' -r | cut -d: -f2))
$(info Installing ingress-nginx:v$(TAG))
$(HELM) upgrade \
--install \
--wait \
--version 4.12.3 \
--namespace ingress-nginx \
--create-namespace \
--set controller.image.tag=$(TAG) \
--set controller.extraArgs.default-backend-service= \
--set controller.service.clusterIP=${SERVICE_IP_PREFIX}.15 \
--set controller.service.type=ClusterIP \
--set controller.config.no-tls-redirect-locations= \
--set-string controller.config.strict-validate-path-type=false \
--set admissionWebhooks.enabled=true \
--set controller.admissionWebhooks.enabled=true \
--set controller.watchIngressWithoutClass=true \
ingress-nginx ingress-nginx/ingress-nginx >/dev/null
Source:
⏰ Extended ACME Authorization Timeout for Greater Stability
To improve the robustness of ACME challenge resolution, especially when dealing with potentially slow ACME servers or network conditions, the authorization timeout has been significantly increased. Previously set to 20 seconds, this timeout could sometimes lead to failed challenges if the ACME server was sluggish in responding or if there were temporary network latencies. This enhancement ensures cert-manager has ample time to receive an authorization response, leading to more reliable certificate issuance.
The internal authorizationTimeout constant in the ACME challenge solver has been adjusted from 20 * time.Second to 2 * time.Minute:
const (
// How long to wait for an authorization response from the ACME server in acceptChallenge()
// before giving up
authorizationTimeout = 2 * time.Minute
)
This change provides a more forgiving window for ACME server responses without requiring any user configuration.
Source:
pkg/controller/acmechallenges/sync.go(44-47)
✨ DefaultPrivateKeyRotationPolicyAlways Promoted to Beta
The DefaultPrivateKeyRotationPolicyAlways feature gate, aimed at enhancing certificate management hygiene, has been promoted to a stable Beta feature in this release and is now enabled by default. This feature ensures that private keys are consistently rotated whenever a certificate is renewed. This is a best practice for security, as it limits the lifespan of private keys and reduces the window of exposure should a key ever be compromised. This promotion reflects its stability and readiness for broader adoption, providing a stronger default security posture for your certificates.
The feature gate’s status in internal/controller/feature/features.go now explicitly marks it as PreRelease: featuregate.Beta and Default: true. No action is required from users, as this feature is now enabled by default, ensuring private keys are always rotated upon renewal.
Source:
Minor Updates & Housekeeping
This release includes routine housekeeping such as updates to the base container images across all supported architectures and minor documentation improvements within the Helm chart README and schema to reflect the latest feature gate statuses.