ipa-ca is an alternative A-record and SAN for an IPA server. Allow it to serve requests to this name rather than issuing a permanent move (301).
< HTTP/1.1 301 Moved Permanently < Date: Tue, 24 Nov 2020 21:12:28 GMT < Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5 < Set-Cookie: ipa_session=;Max-Age=0;path=/ipa;httponly;secure; < X-Frame-Options: DENY < Content-Security-Policy: frame-ancestors 'none' < Location: http://ipa.example.test/ipa/crl/MasterCRL.bin < Cache-Control: no-cache < Set-Cookie: ipa_session=;Max-Age=0;path=/ipa;httponly;secure; < Content-Length: 253 < Content-Type: text/html; charset=iso-8859-1 < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://ipa.example.test/ipa/crl/MasterCRL.bin">here</a>.</p> </body></html>
Just serve up the request.
Yeah, 301 is definitely a bug, because topology can change.
If always serving the request is tricky, either 302 Found or 307 Temporary Redirect could be used instead of 301 Moved Permanently.
I don't know that it's a bug as much as it's inefficient.
The purpose of the redirect code is to allow users to provide a non-FQDN (shortname or IP addr) and have IPA do the right thing by forcing its own FQDN.
In at least the crl case it is valid to allow ipa-ca. This may be the only case in fact. @cheimes may have some ideas on this.
301 is a bug. If a clien'ts CRL request to ipa-ca hits server1 it will get a permanent redirect to server1. Later, if server1 goes away, the client could try the server1 URL directly (that is the semantics of 301).
ipa-ca
server1
But I think I understand what you're saying. The redirect is always back to itself (by FQDN) and therefore not necessary. We should be able to just proxy the data through to the client.
@cheimes and I discussed this a bit.
It might help to put all the scenarios (that we can think of) in a document so we can analyse the potential issues and solutions.
If it makes it easier to analyse the scenarios, and if it doesn't regress anything, I think it is desirable to restrict /ipa and related paths for access via FQDN only, and /ca, /kra, /pki and /acme for access via the ipa-ca.$DOMAIN name only.
/ipa
/ca
/kra
/pki
/acme
ipa-ca.$DOMAIN
IPA has to support $HOSTNAME access for /ca, /kra, /pki and /acme. Otherwise IPA API, local certmonger instance, and other local commands may use an arbitrary server in the topology.
$HOSTNAME
https://github.com/freeipa/freeipa/pull/5294
master:
ipa-4-9:
Metadata Update from @rcritten: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.