Feature #11039
open
Support more specific authorization of wildcard certificates
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
Updated by Anonymous almost 9 years ago
- Related to Feature #7849: trusted_hosts should determine hostname from certificate CN on SSL requests added
Updated by Dominic Cleal almost 9 years ago
- Category set to Core
- Status changed from New to Feedback
Can you just add the *.domain.com to your trusted hosts list?
Updated by Markus Frosch almost 9 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.
Updated by Dominic Cleal almost 9 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.
https://github.com/theforeman/smart-proxy/blob/1.9.0-RC1/lib/sinatra/authorization.rb#L14-L21
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.
Updated by Anonymous almost 9 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.
Updated by Dominic Cleal almost 9 years ago
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.
Updated by Anonymous almost 9 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.
Updated by Dominic Cleal almost 9 years ago
- 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