#8595 Allow ipa-ca as a name for an IPA server
Closed: fixed 4 months ago by rcritten. Opened 5 months ago by rcritten.

Issue

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).

Steps to Reproduce

  1. curl -v http://ipa-ca.example.test/ipa/crl/MasterCRL.bin

Actual behavior

< 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>

Expected behavior

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).

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 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.

master:

  • e731b27 Allow Apache to answer to ipa-ca requests without a redirect
  • 5d8c044 ipatests: Test that ipa-ca.$domain can retrieve CRLs without redirect

ipa-4-9:

  • 4ba6a03 Allow Apache to answer to ipa-ca requests without a redirect
  • b478bf9 ipatests: Test that ipa-ca.$domain can retrieve CRLs without redirect

Metadata Update from @rcritten:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

4 months ago

master:

  • ee7dfc3 Allow mod_auth_gssapi to create and access ccaches in /run/ipa/ccaches
  • 07fa32a upgrade: provide DOMAIN to the server upgrade dictionary

ipa-4-9:

  • 7d1a688 Allow mod_auth_gssapi to create and access ccaches in /run/ipa/ccaches
  • cc51feb upgrade: provide DOMAIN to the server upgrade dictionary

Login to comment on this ticket.

Metadata