From Fedora Project Wiki

Revision as of 13:56, 4 September 2012 by Rcritten (talk | contribs) (Created page with "__NOTOC__ == Introduction == IPA uses the certmonger service to manage automatic certificate renewal. Through 2.2 this covered the server certificates for the 389-DS and Apac...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction

IPA uses the certmonger service to manage automatic certificate renewal. Through 2.2 this covered the server certificates for the 389-DS and Apache instances and for any clients enrolled in IPA.

With 3.0 this adds renewal for the CA subsystem certificates, such as the OCSP service, audit cert, etc.

Testing

To confirm that renewal is working as expected:

  • Install an IPA server (a dogtag CA is configured by default)
# ipa-server-install
  • Get the expiration date of certificates being tracked by certmonger
# getcert list | grep expires
  • Carefully note that not all certs expire at the same time. What you have to do now is find the earliest time and subtract 6 days from it, then set the current system time to that to force the certificates to renew.
# service ntpd stop
# date MMDDhhmmCCYY
  • The certificates should now be in the process of renewal. You can track what is going on with:
# getcert list | grep status
  • The certificates will go through a number of state changes, possibly including:
    • GENERATING_CSR
    • NEED_TO_SUBMIT
    • NEED_TO_SAVE_CERT
    • POST_SAVED_CERT
    • MONITORING
  • The certificates should eventually end up back at MONITORING. It may take several minutes to get there. Messages should also be logged to the syslog.
  • Some certificates may end up in CA_UNREACHABLE. This is fine. It means that the CA was being restarted while the renewal was taking place. If you move time forward to within 6 days of the expiration of the certificate it will be renewed automatically. The only three certificates that should go into this state (any others should be considered a failure) are those in:
    • /etc/dirsrv/slapd-*/alias
    • /etc/httpd/alias

Verification

  • Verify that the certificates are current (should expire 4 years from current date):
# getcert list | grep expires
  • Test that the certificates work:
# kinit admin (password is expired, change it)
# ipa cert-show 1
  • Test that the LDAP server cert works. By default /etc/openldap/ldap.conf should be configured to use TLS, so search for the base, then watch /var/log/dirsrv/slapd-YOURINSTANCE/access to see the TLS connection.
# ldapsearch -x -s base -b dc=example,dc=com

Red Herrings

A number of messages may appear alarming but are nothing to worry about.

systemd sometimes reports startup failures when the service starts fine:

Aug 19 09:42:32 pitbull systemd[1]: Unit pki-cad@pki-ca.service entered failed state.
Aug 19 09:43:15 pitbull systemd[1]: pki-cad@pki-ca.service: main process exited, code=exited, status=143
Aug 19 09:43:15 pitbull systemd[1]: Unit pki-cad@pki-ca.service entered failed state.