#4899 [RFE] mechanism to map principal info into certificate requests
Opened 9 years ago by ftweedal. Modified 6 years ago

Thinking about the DNP3 use case, it would be nice to have some
way of specifying how to generate the appropriate certificate
request for a particular profile based on information stored in
LDAP (including from plugins).

For example, DNP3 SAv5 uses the IEC 62351-8 extension which includes
domain-specific authorization data about a user entity. If that
custom information is stored in LDAP via a plugin, it would be nice
to have a way for admins to define how to map that info into a
certificate request (and then go on to request the certificate, etc).

Profile support (4.2) is the prerequisite for this enhancement.

abokovoy suggested a "template" feature:

Some profiles require a bit of trickery to generate a suitable CSR for use with that profile.

Add the ability to store along with each profile a config template for `openssl req' that can be retrieved by (or for) a user (filled out to the extent possible specifically for that user).

Investigate whether provision should be made for templates for tools other than `openssl'.

Some mores notes:

  • a Q&A user interaction (or answers file) can be used to supply
    information that cannot be gleaned from the directory

  • This command could a) generate an openssl req' config file, or b) generate a CSR (either also generating key or using a nominated key, or c) be made part of theipa cert-request' process so that
    the whole process can be done in a single command.

My preference is for (c).

Addition information from mail discussion:

I agree that it is a good intern project. However, the value of
interpreting the Dogtag profile configuration is debatable; e.g.
knowing that the profile supports SAN doesn't help in knowing what
names to put in it. I see this "mapping" as being FreeIPA-specific
profile configuration (i.e., defined in the IPA certprofile object
but not part of the Dogtag profile configuration).
The very fact that you have to write down ASN.1-friendly description of
the Dogtag profile, feed it to openssl or other tool, produce request
file, upload it via IPA CLI/Web UI, is just too much complication for

Automatically producing config file based on the Dogtag profile is
already a way better than what we have right now. Naturally extending
that to have the process of 'create request config; ask for parameters;
create request; submit request' automated as part of a simple IPA CLI
command would be good. Clearly showing a user that this or that
parameter is optional to enter is good too.

Overall, UXD of issuing certificates is poor. Improvements like the
above move us quite ahead on this road. Not only right now creation of
request config is not documented well, but search engines full of
incomprehensible blog articles that only cover what their respective
authors were interested in. This also leads to creation of cert requests
which are incorrect, like using SAN field to record IP addresses in
OpenStack Director.

Your worry about interpretation of the values in the request is valid.
However, all the above is also done in IPA. I'm not asking right now for
Dogtag-based tool to create cert request files, input values and so on.
This is domain of IPA and partially should be done on server side,
partially at the client side. Thus, if we need to augment Dogtag's
profile with a mapping table defining that a certain cert extension
actually means host or service name, or user, or group attribute's value
-- that's fine. The simplification of the user workflow needs to be done
nevertheless, and what I outline above is part of it, way beyond
defining Dogtag cert profile <-> IPA object property mapping.
Hopefully, this is something we agree on.

For sure; all of the above can be accomplished without IPA having to
understand the Dogtag profile configuration, or implement anything
How can we remove manual generation of CSR config in the example in your
blog article:


This CSR config part is what puzzles majority of users as there is no
documentation on how to do it and given that it should correspond to a
profile at CA in most cases, we can automate the manual work and
copy/paste work done by users.

If we removed that (made automatic), we can also remove use of openssl
to generate request on the client side, by producing csr ourselves on
the client side without user being forced to do so. Right now we have
achieved it with user of certutil from NSS which doesn't require CSR
config but requires explicit values specified as its command line
options. I'd prefer to remove that obscure knowledge too, just ask the
values via IPA CLI as our primary user interface.

The only thing user is left with, is to enter the values that should be
part of the CSR.

Is that possible already?

Yes; someone just needs to write the feature :)
This is exactly what we want to have done as an internship project.

I'm a bit surprised your insistence on crude and awkward user interface
that CSR config + openssl CLI represent here.

We want a simple rule-driven data retrieval system to acquire needed
data from the user interactively and/or from the directory
automatically to construct the CSR. Then construct the CSR and
issue the request.
Yes, exactly. We want to avoid exposing technical details of how
profile and CSR are constructed to allow automation of most common use
cases based on the contextual knowledge already available in FreeIPA and Dogtag.

I bet users would rather have something like

ipa certrequest-add-<profilename> <request_name> [profile options, or
interactive input]

than learning how to create all the manual work outlined above. This
'certrequest-add-<profilename>' command can be purely virtual, based on
the list of profiles that can be obtained under current user

Are you envisaging this command to integrate with Certmonger?

I envisaged this feature as an (optional) enhancement to `ipa
cert-request'. In the simple case where no user interrogation is
required this means that either a public key input or public key
output filename argument is needed. e.g.

ipa cert-request --profile-id=ID --principal=NAME \
--auto --private-key=FILENAME

Or --private-key-out=FILENAME to cause the ipa program to
generate the keypair and write the private key to a file. And an
(optional; sensible default) argument to specify they key type and
The cert-request-<profilename> flow maps nicely to certmonger use.
Sometimes you actually don't need that, though, so it needs to be
conditional. For example, for user certificates being able to request
certificate with little technicalities is important but forcing it to be
tracked by certmonger is probably not so important due to the fact that
the same certificate can be used on multiple machines.

What is highly relevant to this thread however are the prerequisites on the
FreeIPA side to let Intern work on this project. I know for example that
FreeIPA Thin Client work should be done before, so that the interface with
FreeIPA does not have to be redone later. Any other requirements?


  • 10ef594 csrgen: Add code to generate scripts that generate CSRs
  • fc58eff csrgen: Add CSR generation profile for caIPAserviceCert
  • f1a1c6e csrgen: Add a CSR generation profile for user certificates
  • afd7c05 csrgen: Use data_sources option to define which fields are rendered
  • a26cf0d tests: Add tests for CSR autogeneration

Metadata Update from @ftweedal:
- Issue assigned to benlipton
- Issue set to the milestone: FreeIPA 4.5 backlog

7 years ago


  • 39a5d9c csrgen: Automate full cert request flow
  • 4350dcd csrgen: Allow overriding the CSR generation profile
  • ada91c2 csrgen: Support encrypted private keys


  • 72de679 csrgen: hide cert-get-requestdata in CLI

Metadata Update from @jcholast:
- Issue close_status updated to: None

6 years ago


  • 5420e9c csrgen: Remove helper abstraction
  • 136c6c3 csrgen: Change to pure openssl config format (no script)
  • e7588ab csrgen: Modify cert_get_requestdata to return a CertificationRequestInfo
  • a53e178 csrgen: Beginnings of NSS database support

Login to comment on this ticket.