Chat With Us
We are here for you!
Talk to a fellow human.
Feature complete, needs testing.
The dogtag packages are now available in Fedora. The required packages should be pulled in as dependencies when ipa-server is installed.
This just makes the binaries available for the IPA installer script. The installer creates and configures the necessary dogtag components to stand up a CA.
A dogtag CA is installed by default by IPA. To install using a self-signed CA instead of dogtag pass in the
The CA uses a separate instance of DS that is used only for the CA. This instance is named PKI-IPA.
It will install a CA instance into /var/lib/pki-ca.
A copy of the root CA certificate and private key will be put into /root/cacert.p12.
A copy of the CA agent certificate will be put into /root/ca-agent.p12. This agent certificate can be imported into a browser and used to administer CS using the web interface (not recommended).
Use a Different CA to sign the IPA CA certificate
If you have an existing CA you can use it make the IPA CA a subordinate.
This is a three-step process:
# ipa-server-install --external-ca
This will generate a CSR in
Once you have both of these you can continue the installer:
# ipa-server-install --external_cert_file=/root/ipa.crt --external_ca_file=/root/existing_ca.crt
The server caches the answers the first time you run the installer so you don't need to answer the questions again the second time. This cache is removed when the installer is run again.
The paths to the certificate and CA must be absolute paths. The dogtag silent installer will fail if they are not.
Once the installation is complete you will have the same files as a standalone IPA CA: /root/cacert.p12 and /root/ca-agent.p12.
The only difference is that the CA certificate is signed by your external CA in this mode and self-signed in the default mode.
Using Certificates From a Different CA
If don't you want to use the new IPA CA features at all that is ok but you'll need to take a few extra steps.
There are two ways to achieve this:
The step setting
Install and Replace
To use the Install and Replace method do the following:
Install with your own certificates
To use the Install your own method do the following:
Working with Certificates
Once your CA is configured authorized users can perform a number of operations.
Request a certificate
You start with a Certificate Signing Request (CSR). In our case this is a base-64 encoded PKCS#10 request which looks something like:
-----BEGIN CERTIFICATE REQUEST----- MIIBnTCCAQYCAQAwXTELMAkGA1UEBhMCU0cxETAPBgNVBAoTCE0yQ3J5cHRvMRIw EAYDVQQDEwlsb2NhbGhvc3QxJzAlBgkqhkiG9w0BCQEWGGFkbWluQHNlcnZlci5l ... ... 9rsQkRc9Urv9mRBIsredGnYECNeRaK5R1yzpOowninXC -----END CERTIFICATE REQUEST-----
To generate a CSR using OpenSSL run:
% openssl req -new -nodes -out host.csr
You will be prompted for the contents of the certificate subject (country, state, organization, etc). The only critical piece is the common name, this needs to be set to the FQDN of your host.
The CSR is in the file
In NSS you need to start with a cert database so you have an extra step. An NSS CSR generation looks like:
% certutil -N -d /tmp/test % certutil -R -s "CN=ipa.example.com" -d /tmp/test -o test.csr -g 2048 -a
The CSR needs to be passed as one single string on the command-line:
$ ipa cert-request --principal=ldap2/zeus.example.com --add 'MIIBejCB5AIBADA7MQwwCgYDVQQKEwNJUEExEDAOBgNVBAsTB3BraS1pcGExGTAXBgNVBAMTEHpldXMuZ3JleW9hay5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANSiseMKVF/ft44rJDM5XKaMo6jo03TBAC2i61D1GZL6nZ1trl6Oc4YfXccrbQLQ4RGLB6vwDE8vHyYh36OICb1EiWJ+bRaPsn9FaO2mk4qyZp2U/om52BCTSrOq+O+EhTdqLs+hUmUFRDpzmGX3x3UU0JR7cPcvNbcnNQvqfb2NAgMBAAGgADANBgkq > hkiG9w0BAQUFAAOBgQAjWFSgv3KZbcjn8V3rhAnuXG9xFzsqD5XsDRBsIMIrG/KNtw4VZBzuXlU2zOdoYm1vlSlzwep9xWXJi5L8HejyqPiCf2mLB60ZxBJLbe1UQ07+oCBMrxck4VXmnySWekRzfYy9lqV0lP/3A5UC6jbtrqJ6t5mp3yiwkjEzEJGp3A=='
There is also a short-cut method though it isn't working today (Oct 9).
ipa cert-request file://test.csr --principal=ldap3/zeus.example.com --add
Put a cert on hold
$ ipa cert-revoke --revocation-reason=6 0xb
Remove a cert from hold
$ ipa cert-revoke --revocation-reason=6 0xb
Revoke a certificate
$ ipa cert-revoke --revocation-reason=1 0xb revoked: True status: 0
Retrieve a revoked certificate
$ ipa cert-get 0xb certificate: MIIC7D... revocation_reason: 1 status: 0
When you want a certificate to go away you revoke it. RFC 5280 defines the following reasons for revocation:
Note that reason code 7 is not used.
A CRL is generated by the CA that contains a list of revoked certificates. This may be retrieved from an IPA server at: http://ipa.example.com/ipa/crl... with Services
Note this services capability is not in alpha 1
When requesting a certificate a number of things happen:
This is a multi-value attribute that contains the distinguished name of all hosts that are allowed to write the userCertificate attribute of this service. Use the service-add-host and service-remove-host to control access.
This example demonstrates the steps need to be taken by an administrator and a client machine that is attempting to request a certificate for itself. This assumes that the CSR has already been generated and is in the file web.csr in the current directory.
ipa host-add client.example.com --password=secret123 ipa service-add HTTP/client.example.com ipa service-add-host --hosts=client.example.com HTTP/client.example.com ipa rolegroup-add-member --hosts=client.example.com certadmin
ipa-client-install ipa-join -w secret123 kinit -kt /etc/krb5.keytab host/client.example.com ipa -d cert-request file://web.csr --principal=HTTP/client.example.com
What this does
Lets consider the case of a VPN server. On an IPA client we want to set up a VPN tunnel to a remote host, perhaps at another company. To do this we need to create an entry for that remote host, a service principal to store the certificate, then we can issue the cert.
Some of this work needs to be done as an admin:
% kinit admin % ipa host-add vpn.remote.com % ipa service-add vpn/vpn.remote.com % ipa service-add-host --hosts=ipa.example.com vpn/vpn.remote.com
We've created the remote host and a service principal for it, then gave permission for the host ipa.example.com to request a certificate on behalf of vpn.remote.com. This assumes that the certificate request for vpn.remote.com is in the file vpn.csr.
On ipa.example com:
% kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM % ipa cert-request --principal=vpn/vpn.remote.com vpn.csr % ipa service-show vpn/vpn.remote.com