How FreeIPA certificate profiles control what the CA issues
Every certificate FreeIPA issues is shaped by a certificate profile. FreeIPA issues certificates from its integrated Dogtag certificate authority, and a profile is the template the CA applies to each request. It sets the validity period, the key usage and extended key usage, the extensions the certificate carries, and the constraints the CA enforces on the subject and request. If your IdM team is responsible for certificates for services, users or devices, the profile is where those rules live. Before you issue anything at scale, confirm which profile each request type uses, because a request that names the wrong profile will be signed with the wrong rules.
For service certificates, the default profile is caIPAserviceCert, and most TLS requests for hosts and services will use it. Read its settings on your own deployment before relying on them, since the validity period, extensions and allowed names are what determine whether a service certificate is fit for purpose. A custom profile becomes necessary when a certificate has a use the default does not cover, such as S/MIME email certificates that need email protection extended key usage and an email address in the subject or subject alternative name. Other examples include client authentication profiles for devices or specific extension requirements from an internal policy. Each custom profile should have a named owner and a written reason, because it becomes a control point for what the CA is allowed to sign.
Test every profile change on a non-production deployment before it reaches production. Issue a request through each profile, inspect the resulting certificate with a standard X.509 tool, and check that validity, key usage, extensions and subject match the design. Then confirm that the relevant CA ACLs allow only the intended principals to use the profile. DeployOpen can plan, prepare and test profiles and collect the evidence that a compliance assessor will ask for, but independent auditors and certification bodies issue any audit report or certification, and DeployOpen does not. Ask your auditor which profile records they expect to see before you finalize the design.
Profile options and when each fits
This table compares four ways to control what FreeIPA issues: reusing the default service profile, cloning it for a narrower purpose, building a user-facing profile such as S/MIME, and keeping certificates under a sub-CA. Read each row as a decision: the option, what it controls, when it fits and the trade-off you accept.
| Option | What it controls | When it fits | Main trade-off |
|---|---|---|---|
| Default caIPAserviceCert profile | Validity, key usage and extended key usage for service certificates requested through FreeIPA | Web and LDAP service certificates on enrolled hosts where the standard service extensions are acceptable | Changes affect every request that uses it, so broad edits can alter existing issuance behavior |
| Cloned service profile | A copy of the default profile with a narrower validity, subject or extension set for one service class | A service family needs different lifetimes or extensions without disturbing other services | You own the clone, so you must test it after upgrades and review it during audits |
| Custom user-facing profile (for example S/MIME) | Extended key usage such as email protection, subject naming from user identity and possibly key usage flags for signing or encryption | Staff need certificates for mail signing or encryption, and identity checks already exist in FreeIPA | Subject and extension rules must match mail and client expectations, and key escrow or renewal behavior needs separate planning |
| Certificates issued from a sub-CA | Which CA signs the request, and which profiles and principals that CA can use | Device, VPN or Wi-Fi certificates should be limited to a separate signing authority that can be disabled as a group | Adds CA hierarchy to operate, and every profile must be assigned to the right CA |
| Narrowing access with CA ACLs | Which principals may request a given profile from a given CA | Several teams share one CA and each must receive only certain certificate types | ACLs need regular review, and an overly broad rule defeats the separation the profile was meant to provide |
| Testing a profile change before production | A non-production FreeIPA environment or a test request path that exercises the profile | Any change to validity, extensions or subject rules before it reaches live services | Requires a representative test environment, which takes planning effort to keep current |
Creating and testing a custom profile in order
This sequence takes a certificate use case from an inventory entry to a documented, tested FreeIPA profile that issues only the certificates it was designed for. Each step ends with a check so the next step starts from verified ground.
Inventory the certificate use cases
Before touching the CA, list every certificate the profile must serve: the service or device type, the principals who will request it, the hostnames or identities that appear in the subject and subject alternative names, the key type and size the client can generate, and the lifetime the consuming application can tolerate. Owners from the security team and the application team should sign off on this list, since it becomes the basis for the ACL and the test cases. The output is a short table with one row per use case. Confirm that no two use cases need conflicting extensions before going further, because a single profile that tries to serve both will usually end up too permissive.
Clone or define the profile
Start from a copy of the default caIPAserviceCert profile rather than writing one from scratch, so the standard server-side settings stay in place. Create the new profile with the ipa certprofile commands on a test server, giving it a clear name and description that states its purpose and intended principals. Record the profile's configuration export in your change repository. The check is that the new profile appears in the profile list with the expected description and that the exported configuration matches the copy you intended to create.
Set validity and extension settings
Adjust the validity period and the key usage and extended key usage values so they match the use case from your inventory, and add or remove subject alternative name rules only where the use case requires them. Keep extended key usage narrow: a profile meant for TLS server certificates should not also carry client authentication or email protection. Where a use case needs a constraint the profile cannot express, such as a particular subject format, note it as an open item rather than loosening another setting. The check is a diff of the exported profile against the clone, reviewed line by line by someone who did not make the change.
Link the profile to CA ACLs
Create a CA ACL that ties the new profile to the issuing CA and to the specific groups, hosts or services allowed to request it. Avoid broad rules that cover all authenticated users. Confirm the ACL's member lists against the principals from your inventory, and check whether any existing admin bypass permission would let someone outside that list obtain the certificate. The check is an attempted request from an account that should be denied, which must fail, followed by a request from an intended principal, which must succeed.
Test issuance on a non-production server
Run the complete request path on a non-production IdM server with the same profile name and ACL, using a CSR generated on a test host that matches a real use case. Submit the request with ipa cert-request, specifying the profile and principal, and record the request ID and any rejection message. Test at least one allowed request and one denied request, plus a request whose CSR contains a value the profile should reject. The check is that each outcome matches the expected result in your test plan. If the profile rejects a valid request, fix the profile before rolling it out, not the test.
Verify the issued certificate contents
Inspect the certificate that was issued, using a tool such as openssl x509 with the text output, and compare it field by field against the test plan. Check the subject, the subject alternative names, validity dates, key usage, extended key usage, the issuing CA and the serial number. Confirm the certificate chains to the expected CA and that it is trackable by certmonger if the consuming service depends on automatic renewal. Also confirm the certificate is not valid for uses outside its purpose. The check is a written comparison with no unexplained differences. Any mismatch returns you to step three.
Roll out and document the profile
Enable the profile and its ACL on the production topology, apply the same changes in the same order, and confirm with a single allowed request from a real client. Record the profile name, purpose, intended principals, validity, extension settings, ACL members, test results and the owner who approved the change in your operations documentation. Schedule a review date that matches your certificate policy. The output is a rollout record that an auditor or the next administrator can follow without asking the original author. Ask your DeployOpen team, or your internal platform team, to confirm how your change process records these steps.
Profiles for services, users and devices
Service administrators mostly work with the default caIPAserviceCert profile, which FreeIPA uses when a host requests a certificate for a service principal such as HTTP or LDAP. Their job is to confirm that the profile gives the service the names, key usages and validity it needs, and that requests from their hosts are allowed by the correct CA ACLs.
- Subject and SAN names: Confirm that every name clients use, including aliases and load balancer names, appears in the subject alternative name. A certificate that lists only the short host name fails for clients that connect by any other name.
- Key usage and extended key usage: Check that the profile grants server authentication. A certificate without that usage is rejected by browsers and many LDAP clients.
- Validity period: Record the validity the profile applies and make sure renewal monitoring tracks it, since certmonger renews on its own schedule.
- Serial numbers: FreeIPA 4.13.0 uses random serial numbers by default, so any script or ticket process that assumed sequential serials needs review.
- Profile assignment: Verify which profile each service principal maps to, using
ipa certprofile-showand the output of your CA ACL review.
Before changing anything, request a test certificate for one non-production service and inspect its extensions with openssl x509 -text.
Identity teams issuing user certificates, such as S/MIME for email signing and encryption, need profiles that tie the certificate to a person and to an email address. The settings differ from service profiles: the email address must be carried into the certificate, the extended key usages must match the mail use case, and the lifecycle must match staff changes.
- Email address in the SAN: Confirm the profile copies the requester's email address into the rfc822Name field, and that users can request only addresses they own.
- Extended key usage: Set email protection for S/MIME. Add client authentication only where smart card logon is intended, and keep those uses in separate profiles so one certificate does not serve both purposes by default.
- Validity and renewal: Choose a validity your policy supports and agree who approves renewal. User certificates often outlive the role that requested them, so review them when people change roles.
- Key generation and recovery: Decide where private keys are generated and whether encrypted mail must remain decryptable after the certificate expires. The answer affects both the profile and the enrollment method.
- Revocation path: Test that revoking a departed user's certificate publishes to the CRL and that your mail clients check revocation status in your configuration.
Test with one pilot identity, including signing, encryption, decryption and a revocation, before opening enrollment to the wider group.
Device and network teams usually request certificates for VPN gateways, Wi-Fi and 802.1X authentication, and managed endpoints. These certificates are often issued from a sub-CA rather than the main ipa CA, so the profile must match what the device and the network equipment accept, and it must not allow issuance beyond what the device needs.
- Client authentication usage: Set client authentication on device profiles, and confirm the RADIUS server or VPN gateway accepts the chain and the usage.
- Device identifiers: Decide what identifies each device in the subject or SAN, such as an asset tag or a serial-based name. Confirm the identifier is unique and stays stable through re-imaging.
- Validity and automated renewal: Devices that cannot be reached for manual renewal need automation. Confirm the enrollment tool renews before expiry and reports failures.
- Chain delivery: Confirm each device trusts the full chain, including any sub-CA certificate. A missing intermediate is a common cause of authentication failures that look like credential problems.
- Profile and sub-CA limits: Check that the device profile is attached only to the sub-CA the device team owns, so a device profile cannot issue server certificates.
Verify on one device model per platform, including a forced renewal and a revoked certificate, and record the results before rollout.
Security risks when editing certificate profiles
A certificate profile decides what FreeIPA will sign, for whom, and for how long, so a small edit can widen what the CA issues long after the change is made. The cards below cover the risks that most often turn a routine profile change into an issuance or trust problem, and the checks to run before and after editing.
Broad extensions and key usage
A profile carries extension settings such as key usage and extended key usage, and these decide what a certificate can be trusted for. Adding a usage like client authentication or code signing to a profile meant for web servers lets every principal allowed to use that profile obtain a certificate valid for a purpose it was never approved for. Before saving, compare the extended key usage list with the intended use of each service and confirm that no purpose has been added by copying a profile.
Profiles reachable by unintended principals
A profile only matters when a CA ACL connects it to users, hosts or services. An edit that is safe on its own can become dangerous if an existing ACL points at a profile that now has broader settings, or if a new ACL grants a host group access to a sensitive profile. Review the CA ACLs that reference the profile after every change and confirm that each principal group still has only the profiles it needs.
Validity periods that outlast policy
The validity period set in a profile determines how long a certificate stays trusted after issuance, even if the device, user or service that holds it should have lost access. A longer validity period in a profile means certificates issued after the change stay valid past your certificate policy, and revocation becomes the only way to stop them. Confirm the maximum validity against your written policy and check that the lifetime fits the renewal process used by certmonger or other clients.
Weak change control on profile edits
Profile changes take effect immediately for every future request, and FreeIPA does not provide a separate approval step for them. Without a named owner, a reviewer and a written record of the old and new settings, a change can go unnoticed until an auditor or incident responder finds a certificate with unexpected properties. Require a ticket that states the business reason, the before and after values, and the test results, and keep the exported profile configuration under version control.
Renewal master and CRL publication
The first server in a topology handles certificate renewal and CRL publication by default, so profile work should be planned around that server. A profile change tested on a replica that does not act as the renewal master may behave differently once a renewal runs on the master. Confirm which server holds the renewal role and check the CRL publication schedule before applying changes to a production profile.
Backups before every change
A bad profile edit can be reversed only if the previous state is recoverable, so take an ipa-backup before changing any profile in production. The backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so a backup is a safety net for the profile itself and not a substitute for a tested rollback plan. Record the backup location and test restoring it in a lab before relying on it.
Questions buyers ask before building custom profiles
How much effort does a custom FreeIPA certificate profile take?
Effort depends less on the profile file itself than on the decisions behind it. A profile that copies the default service certificate profile and changes one validity setting is a short change. A profile for S/MIME, device or user certificates usually needs more work because you must define the key usage, extended key usage, subject naming, who may request it and how the result is tested. Ask any partner to split the estimate into design, build, test and rollout, and to list which of those steps are one-time and which recur each time a profile changes.
What drives the work up or down on a profile project?
The main drivers are the number of certificate types, the number of systems that consume them, and how many existing rules must be respected. Work goes up when several CA ACLs depend on the profile, when relying systems such as VPN gateways, Wi-Fi controllers or mail clients have strict certificate requirements, or when the certificate must chain to a sub-CA or an externally signed CA. Work goes down when the use cases are few, the consuming systems are documented, and a test environment already mirrors production. Ask for the expected number of profiles, consumers and test cases in the written scope.
Can our internal team build custom profiles without a partner?
Yes, a team with Linux, PKI and FreeIPA administration skills can build and test profiles in-house, and FreeIPA's own documentation covers the profile and CA ACL commands. The risk lies in the surrounding work: validating extensions against each relying system, keeping ACLs consistent with profiles, and reviewing changes before they reach production. Many teams use a partner for the design review and the test plan, then keep routine changes in-house. Confirm which of these skills your team already has before deciding the split.
What do you need from us before a profile engagement starts?
A partner needs four inputs to scope the work accurately:
- An inventory of the certificate types you issue now, the profiles behind them and the CA ACLs that grant access
- A list of relying systems, their certificate requirements and the owners who can test changes
- A non-production FreeIPA environment, ideally built from a recent backup, so changes are tested before they reach production
- A change window agreed with the operations team, plus a rollback plan for the first server that handles renewal and CRL publication
How long does testing a custom profile usually take?
Testing time depends on the number of use cases and the number of relying systems. Each use case needs a request, an issuance, a validation on the consuming system, and a check of renewal and revocation behavior. Plan extra time for systems that enforce strict extension or key usage rules, and for any profile that will be used by a sub-CA. No duration is fixed here, so ask your partner for a test plan listing each use case and the time it needs, and confirm it against your own environment before the change window is booked.
Does a FreeIPA certificate profile change need an audit?
A profile change does not itself require an audit, but the certificates it produces may fall under your compliance program. Auditors and certification bodies, not DeployOpen, decide whether a control is met. Your evidence should show who approved the profile, what it permits, which ACLs grant access, how the change was tested and when it was deployed. Confirm with your auditor which controls apply to your certificates and what records they expect before you change production profiles.
How do we ask for a quote based on a written scope?
DeployOpen does not publish a price list. Engagements are normally fixed-scope, so a quote follows from a written scope that lists the profiles, certificate types, relying systems, test environments and deliverables. Ask for the quote to separate one-time work, such as design and build, from recurring work, such as retainer support or later profile changes. Also ask what is excluded, which assumptions the quote depends on, and how changes to scope after signature are priced.
How DeployOpen scopes and delivers certificate profile work
DeployOpen scopes certificate profile work in a written statement of work before any change is made to your FreeIPA environment. The scope names the profiles in question, such as a change to the default caIPAserviceCert profile or a new custom profile for S/MIME, the certificate types and services they must cover, the CA ACLs that decide who may request them, and the test and cut-over steps. Deliverables and timelines are agreed in that document, so you know what you are buying and what you will receive. Most engagements are fixed-scope, and the quote follows from the written scope rather than from a published price list.
Delivery happens inside your own FreeIPA deployment, in your data center or cloud accounts, not in a DeployOpen-hosted copy. Profile changes are built and exercised first in a non-production IPA domain that mirrors your production settings, including the validity, key usage and extension values, and the CA ACL rules that gate issuance. Each change is recorded with the reason for it, the profile and ACL decisions made, and the test results, so an administrator who inherits the environment can see why a profile looks the way it does. Your team keeps administrative control and receives the configuration and runbook at handover.
Profile work does not end at go-live. Profiles, ACLs and the systems that request certificates through certmonger drift as services and staff change, and FreeIPA releases can change defaults. DeployOpen offers retainers for ongoing support, upgrades and continuous testing of certificate settings. DeployOpen also prepares the systems, configuration records and evidence that your auditors will review. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies make those determinations, so confirm early which evidence your assessor expects.
