Support more specific authorization of wildcard certificates
After updating from 1.7.3 to 1.8.2, we can no longer change the Operating System of a managed host. The web UI fails with an error related to TFTP. We're using a wildcard SSL certificate installed to the Foreman master as well as each remote Smart Proxy; all servers are in the same domain name as the wildcard certificate.
Web UI error:
TFTP Settings for server.domain.com task failed with the following error: ERF12-5472 [ProxyAPI::ProxyException]: Unable to set TFTP boot entry for 00:50:56:a3:57:94 ([RestClient::Forbidden]: 403 Forbidden) for proxy https://dev-foreman01.domain.com:8443/tftp
Foreman Proxy error (DEBUG):
D, [2015-07-07T10:07:41.794749 #26957] DEBUG -- : verifying remote client 100.124.30.61 against trusted_hosts foreman.domain.comforeman01.domain.com100.124.30.61
E, [2015-07-07T10:07:41.795105 #26957] ERROR -- : Untrusted client *.domain.com attempted to access /syslinux/00:50:56:a3:57:94. Check :trusted_hosts: in settings.yml
100.124.30.61 - - [07/Jul/2015 10:07:41] "POST /syslinux/00:50:56:a3:57:94 HTTP/1.1" 403 121 0.0009
#3 Updated by Markus Frosch about 6 years ago
I think his problem is caused by the introduced reverse lookup verification.
Justin seems to have a wildcard cert "*.domain.com", which could work against the trusted_hosts list, but not with forward_verify and not since we test based in the certificate CN, and not the PTR only.
Before my refactoring, we tested the PTR record against trusted_hosts, and the certificate was only authenticated as a client against the smart_proxies's CA, and not if the certificate presented is on the list.
I think a safe solution would be to allow reverse testing to be disabled, while whitelisting the wildcard CN.
#4 Updated by Dominic Cleal about 6 years ago
I don't think forward verification is used at all with HTTPS requests, it only looks to be in the HTTP code path.
So for an HTTPS request, it'll pull the CN from the presented certificate, which is the wildcard hostname and then check the trusted hosts list for it.
#5 Updated by Anonymous about 6 years ago
Dominic, while adding "*.domain.com" to my trusted hosts does work, now any host with access to our wildcard certificate is trusted to make calls to Foreman. From a security view, that's less than ideal (I'll admit using a wildcard is, in itself, its own set of issues).
From my testing, the value of 'fqdn', stored as the CN from the certificate, is what's tripping foreman-proxy up.
#7 Updated by Anonymous about 6 years ago
Correct. I'm thinking along the lines of an enable-able option, defaulting to false as I believe wildcard usage is rare, or as an additional code check.For the code check, it could be along the lines of if code detects that the CN from the certificate is a wildcard, then it requires both:
- First matching the certificate's are valid and domain matches.
- Also requires the remote host name to match against the trusted_hosts list.