We had a few reports where users had a hardware failure (or suspended testing IPA, or certmonger failed and was not restarted) and when they were able to put an IPA server back online the certs were expired.
In this case we currently fail to start completely as DS refuses to start with expired tickets. This means that also the whole DNS and authentication infrastructure fails to operate,
This is not acceptable. Although running with expired certs is really bad. Not being able to start basic network and auth infrastructure is much worse.
It is ok not to allow SSL connection to LDAP at all as long as DS comes up at least for port 389 and works with LDAP+GSSAPI protection (which is used by clients like SSSD, the DNS server and replication).
We should increase the cert life time up to 2 years or more and have tests to enforce the rotation.
389-ds RFE to add option to allow starting with expired cert: https://bugzilla.redhat.com/show_bug.cgi?id=728592
For the validity period I filed RFE https://bugzilla.redhat.com/show_bug.cgi?id=728605
For 2 years change: in 'profiles/ca/caIPAserviceCert.cfg' set 'policyset.serverCertSet.2.constraint.params.range=750' and 'policyset.serverCertSet.2.default.params.range=730'
We may have to carry this change in IPA until the next dogtag release, depending on the timing.
My initial thought is to handle this like expired passwords. The server cert is only processed at startup, so something like this, at startup:
Or, always allow an expired cert, just log warnings
Or, combine these - add another config parameter - nsslapd-handle-expired-cert: ignore - silently allow the expired cert allow - allow the expired cert but warn grace - allow the expired cert but warn until the grace period is over fail - disallow the expired cert and log an error
I do not think we need a grace period.
I suggest: - ignore - silently allow the expired cert - allow - allow the expired cert but warn - fail - disallow the expired cert and log an error
with default "allow"
Replying to [comment:5 dpal]:
I do not think we need a grace period. I suggest: * ignore - silently allow the expired cert * allow - allow the expired cert but warn * fail - disallow the expired cert and log an error with default "allow"
I suggest: * ignore - silently allow the expired cert * allow - allow the expired cert but warn * fail - disallow the expired cert and log an error
+1 here
This has been fixed upstream in 389-ds-base. The fix adds a new config attribute (nsslapd-validate-cert). This new attribute allows one to control the validation of the server certificate used for SSL/TLS.
The valid settings are "on", "off", and "warn". The "on" setting will make the server validate the certificate, treating an invalid certificate as a hard failure that prevents ns-slapd from starting. The "warn" setting will validate the certificate, but the server will start and log an error if the certificate is invalid. The "off" setting will skip certificate validation completely, allowing ns-slapd to start with no reported errors when the certificate is invalid. The default setting is "warn" if the attribute is not specified.
A build has not been made with this change yet, but 389-ds-base-1.2.9.7 should be built soon, which will have this fix.
Fixed in Fedora in 1.2.9.7-1. Waiting for RHEL fix.
master:f59e814
ipa-2-1: 01dcfe4
Fixed in RHEL in version 1.2.9.8-1
Metadata Update from @simo: - Issue assigned to rcritten - Issue set to the milestone: FreeIPA 2.1.1 (bug fixing)
Login to comment on this ticket.