mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-01-11 00:31:56 -06:00
b5b9efeb57
A "cookie" is used with certmonger to track the state of a
request across multiple requests to a CA (in ca-cookie). This
is used with the certmonger POLL operation to submit a request
to the CA for the status of a certificate request. This, along
with the profile, are passed to the certmonger CA helper
scripts via environment variables when a request is made. It is
cleared from the certmonger request once the certificate is
issued.
This CA helper can do a number of things:
- SUBMIT new certicate requests (including the CA)
- POLL for status of an existing certificate request
- For non renewal masters, POLL to see if an updated cert is in
LDAP
A POLL operation requires a cookie so that the state about the
request can be passed to the CA. For the case of retrieving an
updated cert from LDAP there is no state to maintain. It just
checks LDAP and returns either a cert or WAIT_WITH_DELAY if one
is not yet available.
There are two kinds of cookies in operation here:
1. The CERTMONGER_CA_COOKIE environment variable passed via
certmonger to this helper which is a JSON object.
2. The cookie value within the JSON object which contains the
URL to be passed to dogtag.
For the purposes of clarity "cookie" here is the value within
the JSON.
The CERTMONGER_CA_COOKIE is deconstructed and reconstructed as
the request is processed, doing double duty. It initially comes
in as a JSON dict object with two keys: profile and cookie.
In call_handler the CERTMONGER_CA_COOKIE is decomposed into a
python object and the profile compared to the requested profile
(and request rejected if they don't match) and the cookie key
overrides the CERTMONGER_CA_COOKIE environment variable. This is
then reversed at the end of the request when it again becomes a
JSON object containing the profile and cookie.
This script was previously enforcing that a cookie be available on
all POLL requests, whether it is actually required or not. This
patch relaxes that requirement.
The first request of a non-renewal master for an updated certicate
from LDAP is a SUBMIT operation. This is significant because it
doesn't require a cookie: there is no state on a new request. If
there is no updated cert in LDAP then the tracking request goes
into the CA_WORKING state and certmonger will wait 8 hours (as
returned by this script) and try again.
Subsequent requests are done using POLL. This required a cookie
so all such requests would fail with the ca-error
Invalid cookie: u'' as it was empty (because there is no state).
There is no need to fail early on a missing cookie. Enforcement
will be done later if needed (and it isn't always needed). So
if CERTMONGER_CA_COOKIE is an empty string then generate a new
CERTMONGER_CA_COOKIE containing the requested profile and an empty
cookie. It still will fail if certmonger doesn't set a cookie at
all.
An example of a cookie when retrieving a new RA Agent certificate
is:
{"profile": "caServerCert", "cookie": "state=retrieve&requestId=20"}
This will result in this request to the CA:
[09/Jan/2020:14:29:54 -0500] "GET
/ca/ee/ca/displayCertFromRequest?requestId=20&importCert=true&xml=true
HTTP/1.1" 200 9857
For a renewal, the reconstructed cookie will consist of:
{"profile": "caServerCert", "cookie": ""}
https://pagure.io/freeipa/issue/8164
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
|
||
|---|---|---|
| .. | ||
| certmonger | ||
| custodia | ||
| html | ||
| migration | ||
| oddjob | ||
| restart_scripts | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| wsgi | ||
| Makefile.am | ||
| README.schema | ||
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.