Feature #11039
open
Support more specific authorization of wildcard certificates
Added by Anonymous almost 9 years ago.
Updated almost 9 years ago.
Description
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
- Related to Feature #7849: trusted_hosts should determine hostname from certificate CN on SSL requests added
- Category set to Core
- Status changed from New to Feedback
Can you just add the *.domain.com to your trusted hosts list?
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.
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.
So I guess you'd want the option to use authorisation based on the remote host, like HTTP uses, instead of the CN from the cert? If so, that makes some sense.
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.
- Tracker changed from Bug to Feature
- Subject changed from Foreman Smart Proxy fails with untrusted client error to Support more specific authorization of wildcard certificates
- Status changed from Feedback to New
Also available in: Atom
PDF
Updated by 
Updated by