Overview

Infrastructures that offer services via TLS often require an automated mechanism for the regular exchange of certificates. This can be achieved, among other things, by using Certmonger and FreeIPA.

By default, a FreeIPA server is configured to create certificates using a profile with RSA keys. However, if cryptographic requirements exist that, for example, necessitate EC keys, a change to the FreeIPA profile must be made to enable them. Once this is done, these types of keys can also be used via Certmonger – by specifying the adapted profile.

The following article addresses precisely the aforementioned FreeIPA adjustment to demonstrate how certificates with EC keys can also be utilized via Certmonger.

Setup

For the following examples, a FreeIPA server and a corresponding client, which has also been registered as a client with FreeIPA, are required. In this example, both systems are set up with CentOS 9 Stream.

Certmonger

Certmonger typically runs as a daemon in the background and monitors certificates for their expiration. The service can renew certificates if a CA is available for it, or it can also handle the complete deployment of certificates, including key generation, if desired.

The typical sequence for Certmonger is as follows:

1. Creating a key pair
2. Creating a CSR (Certificate Signing Request) with the public key
3. Submitting the CSR to a corresponding CA
4. Verifying the CA’s response
5. Monitoring the certificate for expiration

The design documentation provides further details on this.

EC

EC is also known as ECDSA (Elliptic Curve Digital Signature Algorithm). Elliptic Curve Cryptography (ECC) is used to create such keys, which allows for the use of smaller key lengths. Like RSA, ECDSA also works asymmetrically, meaning a public and a private key are also used here.

Requirements

The prerequisites for the specified setup are as follows:

1. FreeIPA (version used: 4.12.2)
2. At least one client that is to manage certificates using Certmonger (version: 0.79.17)

The FreeIPA server is already configured and offers its services accordingly. The clients, on the other hand, can reach the FreeIPA server, where Certmonger (ipa-client) is already installed.

Creating a Profile for Using EC Keys on FreeIPA

With the default configuration, the FreeIPA server already offers several profiles for certificate creation:


[root@ipa ~]# ipa certprofile-find
------------------
4 profiles matched
------------------
Profile ID: acmeIPAServerCert
Profile description: ACME IPA service certificate profile
Store issued certificates: False

Profile ID: caIPAserviceCert
Profile description: Standard profile for network services
Store issued certificates: True

Profile ID: IECUserRoles
Profile description: User profile that includes IECUserRoles extension from request
Store issued certificates: True

Profile ID: KDCs_PKINIT_Certs
Profile description: Profile for PKINIT support by KDCs
Store issued certificates: False
----------------------------
Number of entries returned 4
----------------------------


It is therefore easiest, for example, to export the existing profile caIPAServicecert and make the necessary changes there. For this, the corresponding profile is exported and saved, for example, in a file named caIPAserviceCert_ECDSA.cfg:


[root@ipa ~]# ipa certprofile-show caIPAserviceCert --out caIPAserviceCert_ECDSA.cfg
-----------------------------------------------------------------
Profile configuration stored in file 'caIPAserviceCert_ECDSA.cfg'
-----------------------------------------------------------------
Profile ID: caIPAserviceCert
Profile description: Standard profile for network services
Store issued certificates: True


In the exported profile, the necessary changes are now made using a simple text editor to support other key types as well:


policyset.serverCertSet.3.constraint.params.keyParameters=nistp256,nistp384,nistp521,sect163k1,nistk163
policyset.serverCertSet.3.constraint.params.keyType=EC
profileId=caIPAserviceCert_ECDSA


The possible values for the parameter keyParameters can be determined with the following command:


[root@ipa ~]# certutil -G -H
[...]
-k key-type Type of key pair to generate ("dsa", "ec", "rsa" (default))
-g key-size Key size in bits, (min 512, max 8192, default 2048) (not for ec)
-q curve-name Elliptic curve name (ec only)
One of nistp256, nistp384, nistp521, curve25519.
If a custom token is present, the following curves are also supported:
sect163k1, nistk163, sect163r1, sect163r2,
nistb163, sect193r1, sect193r2, sect233k1, nistk233,
sect233r1, nistb233, sect239k1, sect283k1, nistk283,
sect283r1, nistb283, sect409k1, nistk409, sect409r1,
nistb409, sect571k1, nistk571, sect571r1, nistb571,
secp160k1, secp160r1, secp160r2, secp192k1, secp192r1,
nistp192, secp224k1, secp224r1, nistp224, secp256k1,
secp256r1, secp384r1, secp521r1,
prime192v1, prime192v2, prime192v3,
prime239v1, prime239v2, prime239v3, c2pnb163v1,
c2pnb163v2, c2pnb163v3, c2pnb176v1, c2tnb191v1,
c2tnb191v2, c2tnb191v3,
c2pnb208w1, c2tnb239v1, c2tnb239v2, c2tnb239v3,
c2pnb272w1, c2pnb304w1,
c2tnb359w1, c2pnb368w1, c2tnb431r1, secp112r1,
secp112r2, secp128r1, secp128r2, sect113r1, sect113r2
sect131r1, sect131r2


For demonstration purposes, the command output is greatly reduced. Only the possible key types and the key size (configurable later in the Certmonger request) are included in the output shown here. By using the passing parameter curve-name, the corresponding command returns the values for the keyParameters.

Of course, when using other key types, client applications must also be considered, as not every browser, for example, supports every available parameter (curve-name). Indications of which key types a browser supports can be determined, for example, via Qualys SSL Labs (in the area of named group).

Additionally, further settings can be made within the profile itself, such as the validity period of the issued certificates.

After these adjustments, the profile (with the new name caIPAserviceCert_ECDSA) can be imported into FreeIPA to use it afterwards. The following command is used for importing:


[root@ipa ~]# ipa certprofile-import caIPAserviceCert_ECDSA --file caIPAserviceCert_ECDSA.cfg
Profile description: Profile for network service with ECDSA
Store issued certificates [True]:
-----------------------------------------
Imported profile "caIPAserviceCert_ECDSA"
-----------------------------------------
Profile ID: caIPAserviceCert_ECDSA
Profile description: Profile for network service with ECDSA
Store issued certificates: True


Thus, another profile is now available in FreeIPA, which can be passed along with certificate requests via Certmonger to obtain corresponding certificates and keys.

Requesting a Certificate via Certmonger

EC

For Certmonger to manage a certificate, a corresponding “Request” must be created. The CA and the appropriate profile to be used for creation are provided with this. Additionally, the storage locations for the private key and the certificate are also specified:


[root@ipa-client-01 ~]# getcert request --ca=IPA --profile=caIPAserviceCert_ECDSA --certfile=/etc/pki/tls/certs/$HOSTNAME.crt --keyfile=/etc/pki/tls/private/$HOSTNAME.key --key-type=ec --subject-name="$HOSTNAME" --principal="HTTP/$HOSTNAME" -g 256


We can observe the successful request in the output as follows:


Number of certificates and requests being tracked: 1.
Request ID '20250206122718':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/etc/pki/tls/private/ipa-client-01.vrc.lan.key'
certificate: type=FILE,location='/etc/pki/tls/certs/ipa-client-01.vrc.lan.crt'
CA: IPA
issuer: CN=Certificate Authority,O=VRC.LAN
subject: CN=ipa-client-01.vrc.lan,O=VRC.LAN
issued: 2025-02-06 13:27:18 CET
expires: 2027-02-07 13:27:18 CET
dns: ipa-client-01.vrc.lan
principal name: HTTP/ipa-client-01.vrc.lan@VRC.LAN
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
profile: caIPAserviceCert_ECDSA
pre-save command:
post-save command:
track: yes
auto-renew: yes


Subsequently, we can now also inspect the created certificate more closely with openssl:


[root@ipa-client-01 ~]# openssl x509 -in '/etc/pki/tls/certs/ipa-client-01.vrc.lan.crt' -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 11 (0xb)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=VRC.LAN, CN=Certificate Authority
Validity
Not Before: Feb 6 12:27:18 2025 GMT
Not After : Feb 7 12:27:18 2027 GMT
Subject: O=VRC.LAN, CN=ipa-client-01.vrc.lan
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:91:15:7d:ac:83:9e:91:cc:9b:ea:f9:0a:5b:53:
03:37:a5:c7:33:69:73:88:38:e4:c1:38:57:8b:b4:
d8:c5:5e:18:8d:83:af:80:fc:9d:64:ab:32:69:dd:
05:50:27:57:be:32:3b:e1:25:10:f3:57:74:e5:42:
a7:16:8e:41:1a
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
03:4B:F3:FE:CB:F9:EC:26:14:F8:61:56:BB:81:6A:CE:A1:DB:4C:0B
Authority Information Access:
OCSP - URI:http://ipa-ca.vrc.lan/ca/ocsp
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://ipa-ca.vrc.lan/ipa/crl/MasterCRL.bin CRL Issuer:
DirName:O = ipaca, CN = Certificate Authority
X509v3 Subject Key Identifier:
00:B5:C7:96:FA:D1:18:D8:6A:11:B4:E0:83:ED:CE:A8:8F:A1:19:7B
X509v3 Subject Alternative Name:
othername: UPN::HTTP/ipa-client-01.vrc.lan@VRC.LAN, othername: 1.3.6.1.5.2.2::, DNS:ipa-client-01.vrc.lan
Signature Algorithm: sha256WithRSAEncryption
[...]


It is relevant that we have indeed received a certificate from the EC profile.

RSA

In parallel to EC keys, we can, of course, also request and monitor other types of certificates with Certmonger. By specifying a different profile, an RSA-based certificate can thus also be requested additionally:


[root@ipa-client-01 ~]# getcert request --ca=IPA --profile=caIPAserviceCert --certfile=/etc/pki/tls/certs/${HOSTNAME}_rsa.crt --keyfile=/etc/pki/tls/private/${HOSTNAME}_rsa.key --subject-name="$HOSTNAME" --principal="HTTP/$HOSTNAME"


The details in the certificate itself can be viewed more closely via the parameter list:


[root@ipa-client-01 ~]# getcert list
Number of certificates and requests being tracked: 2.
Request ID '20250206122718':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/etc/pki/tls/private/ipa-client-01.vrc.lan.key'
certificate: type=FILE,location='/etc/pki/tls/certs/ipa-client-01.vrc.lan.crt'
CA: IPA
issuer: CN=Certificate Authority,O=VRC.LAN
subject: CN=ipa-client-01.vrc.lan,O=VRC.LAN
issued: 2025-02-06 13:27:18 CET
expires: 2027-02-07 13:27:18 CET
dns: ipa-client-01.vrc.lan
principal name: HTTP/ipa-client-01.vrc.lan@VRC.LAN
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
profile: caIPAserviceCert_ECDSA
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20250206123339':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/etc/pki/tls/private/ipa-client-01.vrc.lan_rsa.key'
certificate: type=FILE,location='/etc/pki/tls/certs/ipa-client-01.vrc.lan_rsa.crt'
CA: IPA
issuer: CN=Certificate Authority,O=VRC.LAN
subject: CN=ipa-client-01.vrc.lan,O=VRC.LAN
issued: 2025-02-06 13:33:40 CET
expires: 2027-02-07 13:33:40 CET
dns: ipa-client-01.vrc.lan
principal name: HTTP/ipa-client-01.vrc.lan@VRC.LAN
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
profile: caIPAserviceCert
pre-save command:
post-save command:
track: yes
auto-renew: yes


Here, certificates can also be re-requested or management can be terminated by specifying the request ID. The parameters resubmit and stop-tracking are available for this.

Adjusting the Signature Algorithm

The signature algorithms can also be adjusted via the profile. For this, the entry


policyset.serverCertSet.8.default.params.signingAlg=SHA512withRSA


is adjusted. By default, only a “-” is found there. The algorithm can be selected from the list of options in the parameter


policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA384withRSA,SHA512withRSA,MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC


can be selected.

Subsequently, the changed profile must, of course, be updated in IPA itself. This is done with:


[root@ipa ~]# ipa certprofile-mod caIPAserviceCert_ECDSA --file caIPAserviceCert_ECDSA.cfg
Profile ID: caIPAserviceCert_ECDSA
Profile description: Profile for network service with ECDSA
Store issued certificates: True


A check with openssl then shows the new algorithm:


[root@ipa-client-01 ~]# openssl x509 -in '/etc/pki/tls/certs/ipa-client-01.vrc.lan.crt' -noout -text | grep Sig
Signature Algorithm: sha512WithRSAEncryption
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
[...]


Conclusion

Certmonger in combination with FreeIPA can seamlessly manage certificates with EC keys. Only the configuration of the IPA and the corresponding Certmonger requests need to be adjusted, as shown in the preceding chapters. This allows FreeIPA to be operated excellently in infrastructures that require EC keys. As part of proper operation, it is also recommended to continuously monitor the results of certificate requests in central monitoring.