A flaw was found in Dogtag PKI's ACME responder. The HTTP-01 challenge validator accepts IP address literals (e.g. 127.0.0.1) as dns identifiers without validating that the target address is public. Combined with the default Apache HttpClient behavior of following HTTP redirects, an unauthenticated ACME account holder can force the Dogtag server to send HTTP GET requests to arbitrary internal HTTP endpoints (loopback, link-local, RFC 1918, cloud metadata). When the InMemory database backend is used, the full HTTP response body of the internal target is included in the ACME challenge error and returned to the client, enabling the attacker to read internal HTTP responses. On DS/LDAP and PostgreSQL backends, the SSRF still occurs but the response body is only written to server logs, not returned to the client. The vulnerability exists because ACMEIdentifierValidator.validateSyntaxDNS() treats IP octets as valid DNS labels, ACMEPolicy.validateIdentifier() does not filter non-public addresses, and HTTP01Validator.getResponse() uses HttpClients.createDefault() which follows redirects without validating the destination address.

A flaw was found in Dogtag PKI's ACME responder where the web.xml security constraints use exact URL pattern matching for admin-only enable/disable endpoints. By appending a trailing slash to the URL, an unauthenticated attacker can bypass the Tomcat authentication constraint while RESTEasy still routes the request to the handler, allowing unauthorized toggling of the ACME service state including persistent denial of service.

A flaw was found in Dogtag PKI's ACME responder. The web.xml security constraints protecting the admin-only /v1/enable and /v1/disable endpoints use exact URL pattern matching (/v1/enable and /v1/disable). Due to a path normalization inconsistency between Tomcat's security constraint matching (which requires exact path match per Servlet spec §12.2) and RESTEasy's JAX-RS path routing (which normalizes trailing slashes), a request to /v1/enable/ bypasses the authentication constraint while still being routed to ACMEEnableService.handlePOST(). Neither ACMEEnableService nor ACMEDisableService performs application-level authorization checks — they directly call database.setEnabled(true/false). An unauthenticated remote attacker can exploit this to enable or disable ACME services, allowing persistent denial of service by repeatedly disabling the service, or re-enabling a service that was intentionally disabled by an administrator.