On Thu, Mar 17, 2016 at 7:29 AM, Rob Crittenden <[email protected]> wrote:
--snip-- > Since I now saw three 'Server-Cert' certificates with two accompanying >> keys, I exported the certs and keys, then removed all of the >> 'Server-Cert' entries and then imported back only the key and the most >> recent cert. That fixed most of the errors with the WebUI such that the >> only remaining error was about the PKI-CA. >> > > That might be ok eventually but the nickname change could cause problems > moving forward. You'll need to add certmonger tracking as well if you stick > with the new cert. > > The worrying one is the ipaCert as this agent is used to do some of >> the renewals. NEED_CSR_GEN_PIN generally means that it can't >> authenticate to the NSS database, /etc/httpd/alias in this case. >> Again, need to know exactly what you've done. >> >> >> I didn't touch the ipaCert in the store. Looks like it expired on Feb 22: >> >> Validity: >> Not Before: Tue Mar 04 08:48:49 2014 >> Not After : Mon Feb 22 08:48:49 2016 >> >> I can access the keys in the /etc/httpd/alias store with pwdfile.text. >> Again, no access to store in /var/lib/pki-ca/alias with that same >> password. Should I try to renew ipaCert? >> >> > What I'd suggest is to set the date to Feb 16, run ipactl restrart, then > restart certmonger and see what happens. This assumes, of course, that the > current web server cert is valid then. The Web server cert is valid now from 01/01/2016-01/01/2018 so it should have worked, but setting the date to Feb 16 did not work. Looking through the logs I see: Feb 16 00:29:46 ipa1 certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" will not be valid after 20160222084849. Feb 16 00:29:46 ipa1 certmonger: Certificate named "subsystemCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" will not be valid after 20160222084849. Feb 16 00:29:46 ipa1 certmonger: Certificate named "auditSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" will not be valid after 20160222084949. Feb 16 00:29:46 ipa1 certmonger: Certificate named "Server-Cert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" will not be valid after 20160222084849. which makes me think that certmonger actually wanted to try and work this time. However, then I see: Feb 16 00:29:47 ipa1 certmonger: Server at " https://ipa1.ipa.domain:9443/ca/agent/ca/profileProcess"; replied: 1: Authentication Error Feb 16 00:29:47 ipa1 certmonger: Server at " https://ipa1.ipa.domain:9443/ca/agent/ca/profileProcess"; replied: 1: Authentication Error Feb 16 00:29:47 ipa1 certmonger: Server at " https://ipa1.ipa.domain:9443/ca/agent/ca/profileProcess"; replied: 1: Authentication Error Feb 16 00:29:47 ipa1 certmonger: Server at " https://ipa1.ipa.domain:9443/ca/agent/ca/profileProcess"; replied: 1: Authentication Error I also saw a certmonger decoding error with a certificate after the error. As it prints out the certificate in the log, I tried tracking it down, but no success. Looking at the tomcat logs for the CA startup on port 9443, I see: Feb 16, 2016 12:31:43 AM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-9443 JSSSocketFactory init - exception thrown:java.lang.NullPointerException Looking this up leads me to https://bugzilla.redhat.com/show_bug.cgi?id=1058366. Seeing this bug is not even fixed in IPA version 3.0.x, and I wasn't sure exactly how to implement any solution described there, I couldn't make it work. I'm not sure if this is the reason that certmonger flopped in the first place as it has updated certs before, but, perhaps it was a bug introduced after it was functioning correctly. Should I be able to access anything on SSL port 9443 in the browser just to see if it's working? Steve
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
