I think I'm stuck in a bit of a catch 22 here, I can't update the cert because the cert it's replacing is bad. Is there a way to force it to ignore the existing cert when it goes to update?
Thomas On Mon, Jul 23, 2018 at 8:59 PM Thomas Letherby <xrs...@xrs444.net> wrote: > Hello Brian, > > No problem, I don't expect a SLA on a free mailing list! If it was mission > critical I'd have thrown a wedge of cash at Red Hat a long time ago... > > I do appreciate any help though, some of the documentation is a little > sketchy in places, when my kids grow up a bit and I have time again perhaps > I can help out there. > > I ran the first command three times, then the second. The ipa-update threw > the following error: > > trying https://xipa1.i.domain.net/ipa/json > [try 1]: Forwarding 'schema' to json server ' > https://xipa1.i.domain.net/ipa/json' > cannot connect to 'https://xipa1.i.domain.net/ipa/json': [SSL: > CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:579) > The ipa-certupdate command failed. > > It now shows the following, with the O=Domain cert being in date: > certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > Server-Cert u,u,u > O=DOMAIN,ST=Arizona,C=US CT,C,C > > And the pki-tomcatd service fails to restart with the following error: > > Could not connect to LDAP server host xipa1.i.domain.net port 636 Error > netscape.ldap.LDAPException: Authentication failed (48). > > Thanks again, > > Thomas > > > > On Mon, Jul 23, 2018 at 8:10 PM Rob Crittenden <rcrit...@redhat.com> > wrote: > >> Thomas Letherby wrote: >> > Reading up on the ipa-cacert-manage renew command, according to >> > here https://www.freeipa.org/page/Howto/CA_Certificate_Renewal it >> should >> > have created a new cert and superseded the old certificate, but in my >> > case, perhaps because it has already expired it seems to be still >> > relying on the old cert. >> >> You almost NEVER want to run this command. This renews the CA >> certificate. Nothing else. There is really no point. It is good for >> another 20 years. >> >> > Is this correct? If I have to there's not many certificates issued, and >> > replacing the CA cert on the clients isn't too hard I think so if >> > there's a way of resetting the CA and re-issuing new certs I'm happy to >> > try that, or just cut out the old cert and request new? >> > >> > This isn't in production, so If I need to do something drastic it's not >> > going to be the end of the world. >> >> I'm sorry. I've had your paste open for a week now and keep forgetting >> to respond :-( >> >> So you somehow have a bogus CA entry, serial # 4097. I'm not sure where >> that came from, I assume some self-signed CA of yours. The issuer is >> O=DOMAIN,ST=Arizona,C=US. It needs to go. >> >> Before you do anything backup *.db in /etc/dirsrv/slapd-INSTANCE. You >> can never be too careful. >> >> What I'd recommend is to delete all the CA certs using certutil -D -d >> /etc/dirsrv/slapd-INSTANCE -n "I.DOMAIN.NET IPA CA". You'll run it three >> times. >> >> Then run ipa-certupdate. This should refresh the list with the proper >> CAs. certutil -L to show them again. There should be only one. If Apache >> is working you can use that cert database, /etc/httpd/alias, for >> comparison purposes. >> >> For extra points you can verify it without starting the service: >> >> # certutil -V -u V -d /etc/httpd/alias -n Server-Cert -e -f >> /etc/dirsrv/slapd-INSTANCE/pwdfile.txt >> >> So you have an existing Server-Cert but I can't really be sure which CA >> signed it. The above will tell you if it is currently trusted. It is >> good for another 2 years. >> >> rob >> >> > >> > Thanks, >> > >> > Thomas >> > >> > On Mon, Jul 16, 2018 at 12:24 PM Thomas Letherby <xrs...@xrs444.net >> > <mailto:xrs...@xrs444.net>> wrote: >> > >> > >> > Here's the full listing from slap-d and pki-tomcat: >> > >> > https://pastebin.com/vWf2WVkN >> > >> > Is there any other logs that could help right now? >> > >> > And it is very likely I ran that command,I think I've been through >> > every guide and walk-through remotely related to this! >> > >> > Thomas >> > >> > On Mon, Jul 16, 2018 at 11:52 AM Rob Crittenden < >> rcrit...@redhat.com >> > <mailto:rcrit...@redhat.com>> wrote: >> > >> > Thomas Letherby wrote: >> > > Well, after poking around with the dates and a few restarts of >> > services, >> > > IPA now starts seemingly cleanly at the current date, >> although the >> > > clients still don't seem to want to trust the CA, and I'm >> > still seeing >> > > the old cert crop up. >> > > >> > > If I look at the cert that wasn't updating before, it now >> seems to >> > > contain three certs, the expired one and two new with much >> > longer expiry >> > > dates. >> > > >> > > [root@xipa1 conf.d]# certutil -d >> > /etc/dirsrv/slapd-I-DOMAIN-NET -L -n >> > > "I.DOMAIN.NET <http://I.DOMAIN.NET> <http://I.DOMAIN.NET> IPA >> > CA" | grep Not >> > > Not Before: Sun Jun 17 09:06:38 2018 >> > > Not After : Thu Jun 17 09:06:38 2038 >> > > Not Before: Sun Jun 17 07:24:26 2018 >> > > Not After : Thu Jun 17 07:24:26 2038 >> > > Not Before: Thu Jun 08 06:51:04 2017 >> > > Not After : Mon Jun 18 06:51:04 2018 >> > > >> > > Is this correct, or has it not updated the certificate >> > correctly, if so, >> > > how do I clean it up? >> > >> > This is rather confusing output. I think we need to see the full >> > certutil -L -d output to know what is going on. Did you run >> > ipa-cacert-manage renew at some point? >> > >> > rob >> > >> > > >> > > Thanks, >> > > >> > > Thomas >> > > >> > > >> > > On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS >> > > <christophe.tref...@uni.lu <mailto:christophe.tref...@uni.lu> >> > <mailto:christophe.tref...@uni.lu >> > <mailto:christophe.tref...@uni.lu>>> wrote: >> > > >> > > From that I know you could trigger a refresh by restarting >> > certmonger. >> > > >> > >> On 9 Jul 2018, at 07:38, Thomas Letherby via >> FreeIPA-users >> > >> <freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org> >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org>>> wrote: >> > >> >> > >> Hello Fraser, >> > >> >> > >> As I've been playing around with this before I dig in >> > further I >> > >> pulled the expiry for the certificates across all the >> > places I >> > >> know to look, if I have a cert listed, it's expired: >> > >> >> > >> certutil -d /etc/pki/pki-tomcat/alias -L Up to date >> > >> >> > >> certutil -d /etc/dirsrv/slapd-I-DOMAIN-NET -L >> > >> I.DOMAIN.NET <http://I.DOMAIN.NET> >> > <http://i.domain.net/> IPA CA >> > >> >> > >> certutil -d /etc/httpd/alias -L >> > >> Signing-Cert >> > >> I.DOMAIN.NET <http://I.DOMAIN.NET> >> > <http://i.domain.net/> IPA CA >> > >> >> > >> getcert-list all up to date. >> > >> >> > >> ipa-getcert list all up to date >> > >> >> > >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > "cn=I.DOMAIN.NET <http://I.DOMAIN.NET> >> > >> <http://i.domain.net/> IPA >> > >> CA,cn=certificates,cn=ipa,cn=etc,dc=i,dc=DOMAIN,dc=net" >> > >> Expired >> > >> >> > >> ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > >> uid=pkidbuser,ou=people,o=ipaca "(objectclass=*)" >> > usercertificate >> > >> 1 - Expired >> > >> 2 - Expired >> > >> 3 - In date >> > >> >> > >> I've managed to narrow down the expiries to a crossover >> > of one >> > >> day, and setting the date to that day allows Tomcat-PKI >> > to start, >> > >> but the above results show that the certs haven't updated >> > yet, but >> > >> they may do in the next few hours? >> > >> >> > >> Thomas >> > >> >> > >> >> > >> >> > >> On Sun, Jul 8, 2018 at 11:23 AM Fraser Tweedale >> > >> <ftwee...@redhat.com <mailto:ftwee...@redhat.com> >> > <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>> >> wrote: >> > >> >> > >> On Fri, Jul 06, 2018 at 09:21:44PM -0700, Thomas >> > Letherby wrote: >> > >> > Hello Fraser, >> > >> > >> > >> > The serial numbers appear to match, but if I run >> > >> ipa-certupdate I get the >> > >> > following: >> > >> > >> > >> > ipa-certupdate >> > >> > trying https://server1.i.domain.net/ipa/json >> > >> > Connection >> > to https://server1.i.domain.net/ipa/json failed >> > >> with [SSL: >> > >> > CERTIFICATE_VERIFY_FAILED] certificate verify >> failed >> > >> (_ssl.c:579) >> > >> > >> > >> > Tomcat is the only service that appears to be >> > failing with >> > >> the following >> > >> > error: >> > >> > >> > >> > Internal Database Error encountered: Could not >> > connect to >> > >> LDAP server host >> > >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> > <http://xipa1.i.xrs444.net/> port 636 >> > >> Error netscape.ldap.LDAPException: Unable to >> > >> > create socket: >> org.mozilla.jss.ssl.SSLSocketException: >> > >> > org.mozilla.jss.ssl.SSLSocketException: >> > SSL_ForceHandshake >> > >> failed: (-8181) >> > >> > Peer's Certificate has expired. (-1) >> > >> > >> > >> > But it should now be valid as I set the date back. >> > If I set >> > >> the date to >> > >> > today I get this error: >> > >> > >> > >> > Internal Database Error encountered: Could not >> > connect to >> > >> LDAP server host >> > >> > xipa1.i.xrs444.net <http://xipa1.i.xrs444.net> >> > <http://xipa1.i.xrs444.net/> port 636 >> > >> Error netscape.ldap.LDAPException: Unable to >> > >> > create socket: >> org.mozilla.jss.ssl.SSLSocketException: >> > >> > org.mozilla.jss.ssl.SSLSocketException: >> > SSL_ForceHandshake >> > >> failed: (-12195) >> > >> > Peer does not recognize and trust the CA that >> > issued your >> > >> certificate. (-1) >> > >> > >> > >> > Looks like it can't load because the certificate it >> > uses >> > >> isn't valid, if I >> > >> > roll the clock back so the CA cert is, the >> certificate >> > >> Tomcat is using >> > >> > isn't valid and if I roll forward the CA cert >> isn't. >> > >> > >> > >> > How can I break this catch 22? >> > >> > >> > >> Which is the not-yet-valid certificate at the time to >> > which you >> > >> rolled back? The subsystemCert or the 389DS server >> > certificate? >> > >> >> > >> In either case, you can look in the Dogtag >> > certificate repository >> > >> (ou=certificateRepository,ou=ca,o=ipaca) for a >> > version of the >> > >> certificate that is valid at the relevant time. Copy >> > the cert >> > >> data >> > >> (you can base64-decode the value to get the binary >> > DER certificate >> > >> data). Then you can delete the >> > not-yet-valid-at-that-time >> > >> certificate from the NSSDB and add the appropriate >> > certificate >> > >> using >> > >> >> > >> certutil -d <nssdb-path> -A -i <cert-path> >> > >> >> > >> If the certificate in question is the Dogtag >> > subsystemCert, >> > >> you will >> > >> furthermore need to fix up the data in the >> > uid=pkidbuser entry to >> > >> match the "current" certificate. >> > >> >> > >> HTH, >> > >> Fraser >> > >> >> > >> >> > >> > Thanks, >> > >> > >> > >> > Thomas >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Fri, Jun 29, 2018 at 12:10 AM Fraser Tweedale >> > >> <ftwee...@redhat.com <mailto:ftwee...@redhat.com> >> > <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>> >> > >> > wrote: >> > >> > >> > >> > > On Thu, Jun 28, 2018 at 06:01:18PM -0700, Thomas >> > Letherby >> > >> wrote: >> > >> > > > Hello all, >> > >> > > > >> > >> > > > Here's the info: >> > >> > > > >> > >> > > > certutil -d /etc/dirsrv/slapd-I-domain-NET -L >> > >> > > > >> > >> > > > Certificate Nickname >> > >> > >> Trust >> > >> > > > Attributes >> > >> > > > >> > >> > > > SSL,S/MIME,JAR/XPI >> > >> > > > >> > >> > > > Server-Cert >> > >> > >> u,u,u >> > >> > > > O=domain,ST=Arizona,C=US >> > >> > >> CT,C,C >> > >> > > > I.domain.NET <http://I.domain.NET> >> > <http://i.domain.net/> IPA CA >> > >> CT,C,C >> > >> > > > >> > >> > > > I.domain.NET <http://I.domain.NET> >> > <http://i.domain.net/> IPA CA is out of >> > >> date for those. >> > >> > > > >> > >> > > Try running ipa-certupdate. It will update the >> > IPA CA >> > >> certificate >> > >> > > in the various trust stores including the DS >> NSSDB. >> > >> > > >> > >> > > It reads the certificates from >> > >> > > >> > >> > > cn=YOUR.DOMAIN IPA >> > CA,cn=certificates,cn=ipa,cn=etc,{basedn} >> > >> > > >> > >> > > so you should probably check that the certificate >> > in that >> > >> entry is >> > >> > > up to date also. >> > >> > > >> > >> > > Cheers, >> > >> > > Fraser >> > >> > > >> > >> > > > certutil -L -d /etc/pki/pki-tomcat/alias -n >> > >> 'subsystemCert cert-pki-ca' >> > >> > > -a >> > >> > > > Not After : Fri Jun 05 01:32:01 2020 >> > >> > > > Matches >> > >> > > > ldapsearch -Y GSSAPI -h `hostname` -p 389 -b >> > >> > > > uid=pkidbuser,ou=people,o=ipaca >> "(objectclass=*)" >> > >> usercertificate >> > >> > > > >> > >> > > > Thomas >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > On Thu, Jun 28, 2018 at 5:56 AM Rob Crittenden >> > >> <rcrit...@redhat.com <mailto:rcrit...@redhat.com> >> > <mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>> >> > >> > > wrote: >> > >> > > > >> > >> > > > > Thomas Letherby via FreeIPA-users wrote: >> > >> > > > > > Hello Florence, >> > >> > > > > > >> > >> > > > > > It was the Signing-Cert and >> > the I.domain.NET <http://I.domain.NET> >> > >> <http://i.domain.net/> <http://I.domain.NET >> > >> <http://i.domain.net/>> >> > >> > > IPA >> > >> > > > > > CA cert. By setting the clock back I >> > managed to get >> > >> those to renew, >> > >> > > now >> > >> > > > > > it seems I just need to get tomcat-pki to >> > start. >> > >> > > > > > >> > >> > > > > > The error is: >> > >> > > > > > >> > >> > > > > > Internal Database Error encountered: Could >> not >> > >> connect to LDAP server >> > >> > > > > > host xipa1.i.xrs444.net >> > <http://xipa1.i.xrs444.net> >> > >> <http://xipa1.i.xrs444.net/> < >> http://xipa1.i.xrs444.net >> > >> <http://xipa1.i.xrs444.net/>> port 636 Error >> > >> > > > > > netscape.ldap.LDAPException: Unable to >> > create socket: >> > >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > >> > > > > > org.mozilla.jss.ssl.SSLSocketException: >> > >> SSL_ForceHandshake failed: >> > >> > > > > > (-12195) Peer does not recognize and trust >> > the CA >> > >> that issued your >> > >> > > > > > certificate. (-1) >> > >> > > > > > >> > >> > > > > > certutil -d /etc/pki/pki-tomcat/alias -L >> > >> > > > > > >> > >> > > > > > Certificate Nickname >> > >> > >> Trust >> > >> > > > > > Attributes >> > >> > > > > > >> > >> > > > > > SSL,S/MIME,JAR/XPI >> > >> > > > > > >> > >> > > > > > Server-Cert cert-pki-ca >> > >> > >> u,u,u >> > >> > > > > > ocspSigningCert cert-pki-ca >> > >> > >> u,u,u >> > >> > > > > > O=domain,ST=Arizona,C=US >> > >> > >> CT,C,C >> > >> > > > > > auditSigningCert cert-pki-ca >> > >> > >> u,u,Pu >> > >> > > > > > subsystemCert cert-pki-ca >> > >> > >> u,u,u >> > >> > > > > > caSigningCert cert-pki-ca >> > >> > > CTu,Cu,Cu >> > >> > > > > > >> > >> > > > > > These are all set to expire in 2020 or >> beyond. >> > >> > > > > > >> > >> > > > > > certutil -d /etc/httpd/alias -L Server-Cert >> > >> > > > > > >> > >> > > > > > Certificate Nickname >> > >> > >> Trust >> > >> > > > > > Attributes >> > >> > > > > > >> > >> > > > > > SSL,S/MIME,JAR/XPI >> > >> > > > > > >> > >> > > > > > Signing-Cert >> > >> > >> u,u,u >> > >> > > > > > O=xrs444,ST=Arizona,C=US >> > >> > >> CT,C,C >> > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> > >> <http://i.xrs444.net/> <http://I.XRS444.NET >> > >> <http://i.xrs444.net/>> IPA CA >> > >> > > > > > CT,C,C >> > >> > > > > > Server-Cert >> > >> > >> u,u,u >> > >> > > > > > >> > >> > > > > > I.XRS444.NET <http://I.XRS444.NET> >> > >> <http://i.xrs444.net/> <http://I.XRS444.NET >> > >> <http://i.xrs444.net/>> IPA CA and Signing-Cert are >> the >> > >> > > > > > expired certs here. >> > >> > > > > >> > >> > > > > Don't worry about Signing-Cert. It is the >> > cert used to >> > >> sign the jar >> > >> > > file >> > >> > > > > used to autoconfigure Firefox. You should >> > never need >> > >> to re-sign one >> > >> > > > > again (and this method isn't allowed in >> > modern Firefox >> > >> anyway). >> > >> > > > > >> > >> > > > > rob >> > >> > > > > >> > >> > > > > > >> > >> > > > > > Thomas >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > On Wed, Jun 27, 2018 at 12:20 AM Florence >> > Blanc-Renaud < >> > >> > > f...@redhat.com <mailto:f...@redhat.com> >> > <mailto:f...@redhat.com <mailto:f...@redhat.com>> >> > >> > > > > > <mailto:f...@redhat.com >> > <mailto:f...@redhat.com> <mailto:f...@redhat.com >> > <mailto:f...@redhat.com>>>> wrote: >> > >> > > > > > >> > >> > > > > > On 06/27/2018 07:02 AM, Thomas >> Letherby via >> > >> FreeIPA-users wrote: >> > >> > > > > > > After some fiddling with dates some >> > more I >> > >> seem to have the >> > >> > > HTTPD >> > >> > > > > > cert >> > >> > > > > > > in sync, however it appears the cert >> > signing >> > >> cert is expired. >> > >> > > > > > > >> > >> > > > > > > named also says it's starting, but >> > doesn't >> > >> seem to want to >> > >> > > respond. >> > >> > > > > > > >> > >> > > > > > > I don't have time to dig into it more >> > tonight, >> > >> but let me know >> > >> > > what >> > >> > > > > > > other information or tests I can run >> > and I'll >> > >> get them posted >> > >> > > > > > tomorrow. >> > >> > > > > > > >> > >> > > > > > > Thanks all. >> > >> > > > > > > >> > >> > > > > > > Thomas >> > >> > > > > > > >> > >> > > > > > > On Mon, Jun 25, 2018 at 5:11 PM >> > Thomas Letherby < >> > >> > > xrs...@xrs444.net <mailto:xrs...@xrs444.net> >> > <mailto:xrs...@xrs444.net <mailto:xrs...@xrs444.net>> >> > >> > > > > > <mailto:xrs...@xrs444.net >> > <mailto:xrs...@xrs444.net> >> > >> <mailto:xrs...@xrs444.net <mailto:xrs...@xrs444.net >> >>> >> > >> > > > > > > <mailto:xrs...@xrs444.net >> > <mailto:xrs...@xrs444.net> >> > >> <mailto:xrs...@xrs444.net >> > <mailto:xrs...@xrs444.net>> <mailto:xrs...@xrs444.net >> > <mailto:xrs...@xrs444.net> >> > >> <mailto:xrs...@xrs444.net >> > <mailto:xrs...@xrs444.net>>>>> wrote: >> > >> > > > > > > >> > >> > > > > > > Hello, >> > >> > > > > > > >> > >> > > > > > > I think this is everything >> > (domain name >> > >> changed to protect >> > >> > > the >> > >> > > > > > > guilty!): >> > >> > > > > > > >> > >> > > > > > > https://pastebin.com/bF1KR7VJ >> > >> > > > > > > >> > >> > > > > > Hi Thomas, >> > >> > > > > > >> > >> > > > > > in the provided pastebin, the error >> > 'certutil: >> > >> function failed: >> > >> > > > > > SEC_ERROR_LEGACY_DATABASE: The >> > certificate/key >> > >> database is in an >> > >> > > old, >> > >> > > > > > unsupported format' can be easily >> > explained: >> > >> there is a typo in >> > >> > > the >> > >> > > > > > directory path. >> > >> > > > > > You can try with certutil -d >> > >> /etc/pki/pki-tomcat/alias -L -n >> > >> > > > > <nickname> >> > >> > > > > > (note the pki-tomcat instead of >> > pki-tomcat*d*). >> > >> > > > > > >> > >> > > > > > You mention that the cert signing cert >> is >> > >> expired, can you >> > >> > > clarify >> > >> > > > > > which >> > >> > > > > > certificate this is? Please provide the >> > subject >> > >> name, certificate >> > >> > > > > > nickname and location. >> > >> > > > > > >> > >> > > > > > Flo >> > >> > > > > > > I pulled the same on the replica, >> > which >> > >> appears to be >> > >> > > playing >> > >> > > > > > up too >> > >> > > > > > > in a similar fashion. >> > >> > > > > > > >> > >> > > > > > > I did just notice the date on the >> > replica >> > >> is out, I never >> > >> > > set >> > >> > > > > it >> > >> > > > > > > back when I was trying to get the >> > cert to >> > >> renew. >> > >> > > > > > > >> > >> > > > > > > Let me know if you need anything >> > else. >> > >> > > > > > > >> > >> > > > > > > Thanks, >> > >> > > > > > > >> > >> > > > > > > Thomas >> > >> > > > > > > >> > >> > > > > > > On Sun, Jun 24, 2018 at 8:43 PM >> > Fraser >> > >> Tweedale >> > >> > > > > > <ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com> >> > >> <mailto:ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com>> <mailto:ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com> >> > >> <mailto:ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com>>> >> > >> > > > > > > <mailto:ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com> >> > >> <mailto:ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com>> <mailto:ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com> >> > >> <mailto:ftwee...@redhat.com >> > <mailto:ftwee...@redhat.com>>>>> >> > >> > > > > wrote: >> > >> > > > > > > >> > >> > > > > > > On Fri, Jun 22, 2018 at >> > 11:16:21PM >> > >> -0700, Thomas >> > >> > > Letherby >> > >> > > > > via >> > >> > > > > > > FreeIPA-users wrote: >> > >> > > > > > > > Hello all, >> > >> > > > > > > > I had an issue a short >> > while ago >> > >> with a replica >> > >> > > which >> > >> > > > > > turned >> > >> > > > > > > out to be an >> > >> > > > > > > > expired certificate which >> > I renewed >> > >> and all seemed >> > >> > > good. >> > >> > > > > > > > >> > >> > > > > > > > Seemed... >> > >> > > > > > > > >> > >> > > > > > > > It now appears that >> > although the >> > >> certificate >> > >> > > renewed as >> > >> > > > > > seen >> > >> > > > > > > by getcert >> > >> > > > > > > > -list, it didn't update >> > >> /etc/httpd/alias and so the >> > >> > > > > > httpd and >> > >> > > > > > > tomcat-pki >> > >> > > > > > > > services won't start >> > unless I set >> > >> the date to >> > >> > > before the >> > >> > > > > > > certificate >> > >> > > > > > > > expired, and even then >> > sometimes >> > >> the httpd error_log >> > >> > > > > shows: >> > >> > > > > > > > Unable to verify >> certificate >> > >> 'Server-Cert'. Add >> > >> > > > > > > "NSSEnforceValidCerts off" >> > >> > > > > > > > to nss.conf so the server >> > can start >> > >> until the >> > >> > > problem >> > >> > > > > > can be >> > >> > > > > > > resolved. >> > >> > > > > > > > and the service fails to >> > start. >> > >> > > > > > > > >> > >> > > > > > > Hi Thomas, >> > >> > > > > > > >> > >> > > > > > > Can you please show `getcert >> > list` >> > >> output on the >> > >> > > server in >> > >> > > > > > question, >> > >> > > > > > > as well as the output of >> > >> > > > > > > >> > >> > > > > > > certutil -d >> > /etc/httpd/alias -L >> > >> Server-Cert >> > >> > > > > > > >> > >> > > > > > > and >> > >> > > > > > > >> > >> > > > > > > certutil -d >> > >> /etc/pki/pki-tomcatd/alias -L >> > >> > > <nickname> >> > >> > > > > > > >> > >> > > > > > > for each nickname in the >> > >> /etc/pki/pki-tomcatd/alias >> > >> > > NSSDB. >> > >> > > > > > > >> > >> > > > > > > And Certmonger journal >> > output. And >> > >> pki debug log >> > >> > > > > > > >> /var/log/pki/pki-tomcat/ca/debug. >> > >> > > > > > > >> > >> > > > > > > It is strange that `getcert >> list' >> > >> shows an up to date >> > >> > > > > > certificate >> > >> > > > > > > while the actual certificate >> > that is >> > >> being tracked is >> > >> > > > > > expired... >> > >> > > > > > > >> > >> > > > > > > Thanks, >> > >> > > > > > > Fraser >> > >> > > > > > > >> > >> > > > > > > > I've tried resubmitting >> the >> > >> certificate, and it >> > >> > > doesn't >> > >> > > > > > seem >> > >> > > > > > > to throw an >> > >> > > > > > > > error, but it doesn't >> > update /alias >> > >> either. >> > >> > > > > > > > Trying to access the >> > server via the >> > >> web page shows >> > >> > > the >> > >> > > > > old >> > >> > > > > > > certificate >> > >> > > > > > > > still in use. >> > >> > > > > > > > I see the same certificate >> > error >> > >> with the replica >> > >> > > > > server, >> > >> > > > > > > which was freshly >> > >> > > > > > > > rebuilt and added last >> week. >> > >> > > > > > > > I've doubtless dug further >> > into the >> > >> hole trying to >> > >> > > > > > > troubleshoot this, so I >> > >> > > > > > > > probably need to start >> > from the >> > >> beginning again, >> > >> > > and a >> > >> > > > > > > pointer in the right >> > >> > > > > > > > direction would be a great >> > help! >> > >> > > > > > > > >> > >> > > > > > > > A getcert list shows all >> the >> > >> certificates expiry >> > >> > > dates >> > >> > > > > well >> > >> > > > > > > into the future. >> > >> > > > > > > > >> > >> > > > > > > > How can I get the certs >> > back in >> > >> sync? I've found a >> > >> > > few >> > >> > > > > > guides >> > >> > > > > > > and most seem >> > >> > > > > > > > to be for earlier >> > versions, and I'm >> > >> not sure if >> > >> > > they're >> > >> > > > > > still >> > >> > > > > > > current. >> > >> > > > > > > > >> > >> > > > > > > > I can post whatever logs >> > you think >> > >> will help, I'm >> > >> > > > > > afraid I'm >> > >> > > > > > > not familiar >> > >> > > > > > > > enough with them all to >> > tell which >> > >> are the most >> > >> > > > > > relevant. Is >> > >> > > > > > > there a guide >> > >> > > > > > > > for the logs? >> > >> > > > > > > > >> > >> > > > > > > > Thanks for any help you >> > can give, >> > >> > > > > > > > >> > >> > > > > > > > Thomas >> > >> > > > > > > >> > >> > > > > > > > >> > >> _______________________________________________ >> > >> > > > > > > > FreeIPA-users mailing >> list -- >> > >> > > > > > > >> > freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org> >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org>> >> > >> > > > > > >> > <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org> >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org>>> >> > >> > > > > > > >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org> >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org>> >> > >> > > > > > >> > <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org> >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org>>>> >> > >> > > > > > > > To unsubscribe send an >> > email to >> > >> > > > > > > >> > >> freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org> >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org>> >> > >> > > > > > >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org> >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org>>> >> > >> > > > > > > >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org> >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org>> >> > >> > > > > > >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org> >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org>>>> >> > >> > > > > > > > Fedora Code of Conduct: >> > >> > > > > > > >> > https://getfedora.org/code-of-conduct.html >> > >> > > > > > > > List Guidelines: >> > >> > > > > > > >> > >> >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> > >> > > > > > > > List Archives: >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > >> > >> >> > > >> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/CAXKCVP42DLWJQV2TAJFFCR2NG2CBO27/ >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > > >> > _______________________________________________ >> > >> > > > > > > FreeIPA-users mailing list -- >> > >> > > freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org> >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org>> >> > >> > > > > > >> > <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org> >> > >> <mailto:freeipa-users@lists.fedorahosted.org >> > <mailto:freeipa-users@lists.fedorahosted.org>>> >> > >> > > > > > > To unsubscribe send an email to >> > >> > > > > > >> > freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org> >> > >> <mailto:freeipa-users-le...@lists.fedorahosted.org >> > <mailto:freeipa-users-le...@lists.fedorahosted.org>> >> > >> > > > > > > >
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/EQN3CWY7GRRCZDRRK2S6F4XKTF5QBKTI/
