Roderick Johnstone wrote: > On 31/01/2018 20:36, Rob Crittenden via FreeIPA-users wrote: >> Roderick Johnstone via FreeIPA-users wrote: >>> On 25/01/2018 16:56, Roderick Johnstone via FreeIPA-users wrote: >>>> On 25/01/2018 13:43, Rob Crittenden via FreeIPA-users wrote: >>>>> Roderick Johnstone via FreeIPA-users wrote: >>>>>> On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote: >>>>>>> Roderick Johnstone via FreeIPA-users wrote: >>>>>>>> On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote: >>>>>>>>> Roderick Johnstone via FreeIPA-users wrote: >>>>>>>>>> On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote: >>>>>>>>>>> Roderick Johnstone via FreeIPA-users wrote: >>>>>>>>>>>> On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote: >>>>>>>>>>>>> Roderick Johnstone via FreeIPA-users wrote: >>>>>>>>>>>>>> On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote: >>>>>>>>>>>>>>> Roderick Johnstone via FreeIPA-users wrote: >>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Our freeipa certificates need to be renewed due to passing >>>>>>>>>>>>>>>> their >>>>>>>>>>>>>>>> expiry >>>>>>>>>>>>>>>> dates. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> While some certificates have renewed ok, the ipaCert and >>>>>>>>>>>>>>>> auditSigningCert are renewing but the new certificates >>>>>>>>>>>>>>>> have the >>>>>>>>>>>>>>>> wrong >>>>>>>>>>>>>>>> Subject. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Environment is: >>>>>>>>>>>>>>>> serverA (CRL, first, master) RHEL 7.3, ipa 4.4 >>>>>>>>>>>>>>>> serverB (replica) RHEL 7.3, ipa 4.4 >>>>>>>>>>>>>>>> serverC (replica) RHEL 7.4, ipa 4.5 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Once there are renewed certificates with the wrong Subject >>>>>>>>>>>>>>>> present, >>>>>>>>>>>>>>>> there are various problems with renewing the remaining >>>>>>>>>>>>>>>> certificates, >>>>>>>>>>>>>>>> which I think might be related to the bad Subject: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) When just ipaCert has the wrong subject no further >>>>>>>>>>>>>>>> renewals >>>>>>>>>>>>>>>> happen >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) When auditSigningCert has the wrong subject the ipa >>>>>>>>>>>>>>>> pki-tomcatd >>>>>>>>>>>>>>>> service will not start and no further renewals happen. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've been round the following loop many times on >>>>>>>>>>>>>>>> ServerA, our >>>>>>>>>>>>>>>> first >>>>>>>>>>>>>>>> master: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) Restore good certificates from backup >>>>>>>>>>>>>>>> 2) Put the clock back to a time when certificates are all >>>>>>>>>>>>>>>> valid >>>>>>>>>>>>>>>> 3) Resubmit certificates for renewal >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Each time the ipaCert renews it has the same wrong >>>>>>>>>>>>>>>> Subject. The >>>>>>>>>>>>>>>> wrong >>>>>>>>>>>>>>>> Subject includes the host name of one of our ipa client >>>>>>>>>>>>>>>> systems. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Each time the auditSigningCert renews it has the same wrong >>>>>>>>>>>>>>>> Subject >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>> a different subject to the ipaCert. The wrong Subject in >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> case >>>>>>>>>>>>>>>> includes the host name of a system which has never been an >>>>>>>>>>>>>>>> ipa >>>>>>>>>>>>>>>> client, >>>>>>>>>>>>>>>> but might have been added and removed with ipa host-add >>>>>>>>>>>>>>>> and ipa >>>>>>>>>>>>>>>> host-del >>>>>>>>>>>>>>>> for testing something, a while ago. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As far as I can see, the "cert_subject" is set correctly >>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>> file >>>>>>>>>>>>>>>> /var/lib/certmonger/<request id> until the point at >>>>>>>>>>>>>>>> which the >>>>>>>>>>>>>>>> certificate is actually renewed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'd be very grateful for some pointers as to which >>>>>>>>>>>>>>>> configuration >>>>>>>>>>>>>>>> options >>>>>>>>>>>>>>>> and logs to check through to resolve this problem on our >>>>>>>>>>>>>>>> production >>>>>>>>>>>>>>>> system. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If its of any relevance we did change which server is the >>>>>>>>>>>>>>>> first >>>>>>>>>>>>>>>> master >>>>>>>>>>>>>>>> some time ago. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger >>>>>>>>>>>>>>> to see >>>>>>>>>>>>>>> what >>>>>>>>>>>>>>> the subject is. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not seeing any obvious CSR fields in the >>>>>>>>>>>>>> /etc/pki/pki-tomcat/ca/CS.cfg file. >>>>>>>>>>>>> >>>>>>>>>>>>> foo.bar.certreq= >>>>>>>>>>>>> >>>>>>>>>>>>>> The CSR in the certmonger requests file for the >>>>>>>>>>>>>> auditSigningCert >>>>>>>>>>>>>> seems >>>>>>>>>>>>>> to be showing with the correct Subject. This is different >>>>>>>>>>>>>> from >>>>>>>>>>>>>> the bad >>>>>>>>>>>>>> subject showing in the requests file field: >>>>>>>>>>>>>> cert_subject= >>>>>>>>>>>>> >>>>>>>>>>>>> The value of cert_subject comes from the issued certificate. >>>>>>>>>>>>> >>>>>>>>>>>>>> and the Subject which is showing in the 'getcert list' output >>>>>>>>>>>>>> (which is >>>>>>>>>>>>>> the same as that in the cert_subject= field.> >>>>>>>>>>>>>> I'm not quite sure what this all means. >>>>>>>>>>>>> >>>>>>>>>>>>> It is displayed from the data within the tracked certmonger >>>>>>>>>>>>> request. >>>>>>>>>>>>> >>>>>>>>>>>>> certmonger logs to syslog so you can check there or you can >>>>>>>>>>>>> stop >>>>>>>>>>>>> the >>>>>>>>>>>>> process and run it manually with: certmonger -n -d 9 2>&1 | >>>>>>>>>>>>> tee >>>>>>>>>>>>> certmonger.log >>>>>>>>>>>>> >>>>>>>>>>>>> That will provide a lot of debugging output that may show >>>>>>>>>>>>> what is >>>>>>>>>>>>> going on. >>>>>>>>>>>> >>>>>>>>>>>> I've restored certificate databases from backup and put the >>>>>>>>>>>> clock >>>>>>>>>>>> back >>>>>>>>>>>> to a time when certificates are valid and renewed the >>>>>>>>>>>> ocspSigining >>>>>>>>>>>> certificate with: >>>>>>>>>>>> getcert resubmit -N "CN=OCSP Subsystem,O=<REALM>" -i >>>>>>>>>>>> 20161124081302 >>>>>>>>>>>> >>>>>>>>>>>> (I've previously tried without the -N with similar results) >>>>>>>>>>>> >>>>>>>>>>>> What I am seeing in the certmonger logs is: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert >>>>>>>>>>>> cert-pki-ca'. >>>>>>>>>>>> 2017-10-23 00:05:28 [438] Converted private key >>>>>>>>>>>> 'ocspSigningCert >>>>>>>>>>>> cert-pki-ca' to public key. >>>>>>>>>>>> 2017-10-23 00:05:28 [439] Located the certificate >>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>> cert-pki-ca". >>>>>>>>>>>> 2017-10-23 00:05:28 [440] 0x1d Certificate named >>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>> cert-pki-ca" in token "NSS Certificate DB" in database >>>>>>>>>>>> "/etc/pki/pki-tomcat/alias" will not be valid after >>>>>>>>>>>> 20171025122401. >>>>>>>>>>>> 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert >>>>>>>>>>>> cert-pki-ca'. >>>>>>>>>>>> 2017-10-23 00:05:28 [442] Converted private key >>>>>>>>>>>> 'ocspSigningCert >>>>>>>>>>>> cert-pki-ca' to public key. >>>>>>>>>>>> 2017-10-23 00:05:28 [443] Located the certificate >>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>> cert-pki-ca". >>>>>>>>>>>> 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert >>>>>>>>>>>> cert-pki-ca'. >>>>>>>>>>>> 2017-10-23 00:05:28 [444] Converted private key >>>>>>>>>>>> 'ocspSigningCert >>>>>>>>>>>> cert-pki-ca' to public key. >>>>>>>>>>>> 2017-10-23 00:05:39 [581] Found a certificate with the same >>>>>>>>>>>> nickname but >>>>>>>>>>>> different subject, removing certificate "ocspSigningCert >>>>>>>>>>>> cert-pki-ca" >>>>>>>>>>>> with subject "CN=OCSP Subsystem,O=<REALM>". >>>>>>>>>>>> 2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert >>>>>>>>>>>> cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca". >>>>>>>>>>>> 2017-10-23 00:05:39 [583] Located the certificate >>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>> cert-pki-ca". >>>>>>>>>>>> 2017-10-23 00:05:39 [48576] Adding hook >>>>>>>>>>>> "/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert >>>>>>>>>>>> cert-pki-ca"" (0). >>>>>>>>>>>> 2017-10-23 00:10:43 [942] 0x1d Certificate named >>>>>>>>>>>> "ocspSigningCert >>>>>>>>>>>> cert-pki-ca" in token "NSS Certificate DB" in database >>>>>>>>>>>> "/etc/pki/pki-tomcat/alias" issued by CA and saved. >>>>>>>>>>>> >>>>>>>>>>>> I now have a date valid ocspSigningCertificate, but with the >>>>>>>>>>>> wrong >>>>>>>>>>>> subject, and a broken certificate system which will no longer >>>>>>>>>>>> start. >>>>>>>>>>>> >>>>>>>>>>>> ipactl status >>>>>>>>>>>> ... >>>>>>>>>>>> pki-tomcatd Service: STOPPED >>>>>>>>>>>> >>>>>>>>>>>> I can't renew other expired certificates. >>>>>>>>>>>> >>>>>>>>>>>> I also note that there is now no key for >>>>>>>>>>>> ocspSigningCertificate as >>>>>>>>>>>> shown >>>>>>>>>>>> by: >>>>>>>>>>>> certutil -K -d /etc/pki/pki-tomcat/alias >>>>>>>>>>>> >>>>>>>>>>>> I wonder if this is because the certificate subject changed? >>>>>>>>>>>> There >>>>>>>>>>>> was a >>>>>>>>>>>> key before the certificate renewed. >>>>>>>>>>>> >>>>>>>>>>>> The ca debug logs are showing: >>>>>>>>>>>> >>>>>>>>>>>> [23/Oct/2017:00:55:47][localhost-startStop-1]: Found cert by >>>>>>>>>>>> nickname: >>>>>>>>>>>> 'ocspSigningCert cert-pki-ca' with serial number: 268370108 >>>>>>>>>>>> [23/Oct/2017:00:55:47][localhost-startStop-1]: converted to >>>>>>>>>>>> x509CertImpl >>>>>>>>>>>> [23/Oct/2017:00:55:47][localhost-startStop-1]: SigningUnit: >>>>>>>>>>>> Certificate >>>>>>>>>>>> object not found >>>>>>>>>>>> Certificate object not found >>>>>>>>>>>> at >>>>>>>>>>>> com.netscape.ca.SigningUnit.init(SigningUnit.java:184) >>>>>>>>>>>> >>>>>>>>>>>> Any help in repairing my broken ipa system will be much >>>>>>>>>>>> appreciated. >>>>>>>>>>> >>>>>>>>>>> Sorry for the delay. I think my previous reading of the >>>>>>>>>>> certmonger >>>>>>>>>>> csrgen code was wrong. >>>>>>>>>>> >>>>>>>>>>> IIRC in your certmonger entry the cert_subject has the hostname >>>>>>>>>>> value >>>>>>>>>>> right? Do you also have cert_subject_der? >>>>>>>>>>> >>>>>>>>>>> You can decode that by: >>>>>>>>>>> >>>>>>>>>>> 1. Running a hex-to-bin, something hacky like this in python: >>>>>>>>>>> >>>>>>>>>>> import binascii >>>>>>>>>>> >>>>>>>>>>> hex_string = "<hex value>" >>>>>>>>>>> >>>>>>>>>>> binary_string = binascii.unhexlify(hex_string) >>>>>>>>>>> >>>>>>>>>>> fd = open("out", "wb") >>>>>>>>>>> fd.write(binary_string) >>>>>>>>>>> fd.close() >>>>>>>>>>> >>>>>>>>>>> 2. Run: openssl asn1parse -in out -inform der >>>>>>>>>>> >>>>>>>>>>> I'm going to assume this also has the hostname encoded in it. >>>>>>>>>> >>>>>>>>>> Hi Again >>>>>>>>>> >>>>>>>>>> Yes, correct. The cert_subject_der does have the bad CN with the >>>>>>>>>> hostname encoded in it. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Can you try this: >>>>>>>>>>> >>>>>>>>>>> 1. Make a backup of the request file (just in case) > 2. Remove >>>>>>>>>>> cert_subject_der >>>>>>>>>>> 3. Modify cert_subject to be CN=OCSP Subsystem,O=<YOUR_REALM> >>>>>>>>>>> 3. Try the renewal again >>>>>>>>>> >>>>>>>>>> I ran though all of this, checking that the request file was >>>>>>>>>> still >>>>>>>>>> what >>>>>>>>>> we wanted after restarting certmonger with verbose logging, >>>>>>>>>> restoring >>>>>>>>>> all the databases, fixing permissions, checking keys etc., and >>>>>>>>>> ran the >>>>>>>>>> getcert resubmit. >>>>>>>>>> >>>>>>>>>> It still generates a certificate with the bad CN including a >>>>>>>>>> hostname. >>>>>>>>>> >>>>>>>>>> Then the pki-tomcat server fails to start again. >>>>>>>>>> >>>>>>>>>> Other things I have checked are: >>>>>>>>>> 1) The csr= field in the (modified) request file has the correct >>>>>>>>>> subject. >>>>>>>>>> >>>>>>>>>> 2) The dogtag ca debug log file is showing: >>>>>>>>>> processRenewal: origNotAfter =Wed Oct 25 13:24:01 BST 2017 >>>>>>>>>> processRenewal: orig subj dn =CN=OCSP Subsystem,O=AST.CAM.AC.UK >>>>>>>>>> ... >>>>>>>>>> RenewalSubmitter: renewal original profileId=caIPAserviceCert >>>>>>>>>> RenewalSubmitter: for renewal, original authenticator raCertAuth >>>>>>>>>> found >>>>>>>>>> CertProcessor: No authenticator credentials required >>>>>>>>>> processRenewal: set original Inputs into profile Context >>>>>>>>>> RenewalSubmitter: setInputsIntoContext() getting input name= >>>>>>>>>> cert_request_type >>>>>>>>>> RenewalSubmitter: setInputsIntoContext() setting value in >>>>>>>>>> ctx:pkcs10 >>>>>>>>>> RenewalSubmitter: setInputsIntoContext() getting input name= >>>>>>>>>> cert_request >>>>>>>>>> RenewalSubmitter: setInputsIntoContext() setting value in >>>>>>>>>> ctx:<hex >>>>>>>>>> encoded csr> >>>>>>>>>> ... >>>>>>>>>> Finish parsePKCS10 - CN=<HOSTNAME>,O=<REALM> >>>>>>>>>> >>>>>>>>>> The hex encoded csr in the last line decodes to have the bad >>>>>>>>>> subject >>>>>>>>>> where the hostname is one of our other ipa servers. >>>>>>>>>> >>>>>>>>>> The certificate always getthe same hostname in the bad subject >>>>>>>>>> cn. >>>>>>>>>> >>>>>>>>>> Do you have any other ideas of things to check to find out what's >>>>>>>>>> generating the bad subject? >>>>>>>>> >>>>>>>>> The order certmonger uses for the subject is: >>>>>>>>> >>>>>>>>> 1. cert_subject_der >>>>>>>>> 2. If there is no DER, try to encode cert_subject >>>>>>>>> 3. If that fails try again a different way >>>>>>>>> 4. If it fails yet again use CN=localhost >>>>>>>>> >>>>>>>>> It is baffling that it would pick a hostname much less one that >>>>>>>>> certmonger shouldn't even know about. >>>>>>>> >>>>>>>> Indeed, and if I try to renew other certificates for some of >>>>>>>> them it >>>>>>>> chooses other host names that should not be known about. Each >>>>>>>> certificate seems to get the same bad hostname each time I try to >>>>>>>> renew. >>>>>>>> >>>>>>>>> >>>>>>>>> I assume the CSR found in the dogtag logs matches the csr value >>>>>>>>> in the >>>>>>>>> certmonger request? >>>>>>>> >>>>>>>> No, its different. The issued certificate matches the csr seen in >>>>>>>> dogtag >>>>>>>> which makes sense. But the csr in the dogtag logs has the bad >>>>>>>> subject. >>>>>>>> The csr in the request directory file has the good subject. >>>>>>>> >>>>>>>>> >>>>>>>>> Can you share the certmonger request file privately? >>>>>>>> >>>>>>>> Yes, certainly. >>>>>>>> >>>>>>>> Thanks for your continued help on this. >>>>>>> >>>>>>> Let's try this. We'll drop the current request and create a new one. >>>>>>> >>>>>>> Stop tomcat, restore the old cert database, start tomcat, then: >>>>>>> >>>>>>> # getcert stop-tracking -i <request id> >>>>>>> # getcert start-tracking -c dogtag-ipa-ca-renew-agent -n >>>>>>> "ocspSigningCert cert-pki-ca" -d /etc/pki/pki-tomcat/alias -P >>>>>>> <pin> -B >>>>>>> /usr/libexec/ipa/certmonger/stop_pkicad -C >>>>>>> '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert >>>>>>> cert-pki-ca"' >>>>>>> >>>>>>> Then try resubmitting the request. >>>>>>> >>>>>> Hi Rob >>>>>> >>>>>> When you say 'stop tomcat', I'm just doing an ipactl stop. That is >>>>>> stopiing the ipa pki-tomcat service. Is that good enough or are there >>>>>> other services that need stopping too? >>>>>> >>>>>> I tried the stop-tracking/start-tracking. Exactly the same result as >>>>>> before. Same hostname appears in the subject CN field of the new >>>>>> certificate and then the pki-tomcat service won't start. >>>>>> >>>>>> I've also been back and redone the manual submits changing the >>>>>> point at >>>>>> which I copied in the edited request as I wondered if there was some >>>>>> caching of csr's going on in certmonger and it was remembering a >>>>>> previous request it had read on startup before I replaced the >>>>>> request file. >>>>>> >>>>>> But nothing seems to stop dogtag issuing a certificate with the >>>>>> Subject >>>>>> CN being that host name. >>>>>> >>>>>> Is it possible that dogtag is somehow overriding the Subject its >>>>>> being >>>>>> explicitly given? >>>>>> >>>>>> FWIW the CSR in the dogtag debug log is always identical, but I guess >>>>>> thats expected if the CSR information is always the same. >>>>>> >>>>>> I'm not sure if its possible to increase the verbosity on the dogtag >>>>>> side. Can you advise please? >>>>>> >>>>>> I've been assuming that its the bad subject that is preventing the >>>>>> pki-tomcat from starting after the new certificate is issued. Does >>>>>> that >>>>>> make sense to you? >>>>>> >>>>>> I wonder where we can go from here? There must be a good reason for >>>>>> whats happening! >>>>> >>>>> Let's step back and gather some more information. >>>>> >>>>> Can you restore the files again and send me the output of: >>>>> >>>>> # getcert list >>>>> >>>>> # certutil -L -d /etc/pki/pki-tomcat/alias/ -n "ocspSigningCert >>>>> cert-pki-ca" >>>> >>>> Hi Rob >>>> >>>> You should have the output you requested by private email now. >>>> >>>>> >>>>> And the exact commands you are using to do all this, including >>>>> re-issuing the cert >>>> >>>> Thats a great idea. Maybe I'm just doing something in the wrong order. >>>> >>>>> >>>>> Using ipactl is fine. You just don't want to touch the NSS databases >>>>> while the service is running. Similarly you probably don't want to >>>>> mess >>>>> with certmonger requests while it is running as it won't see the >>>>> changes >>>>> until it restarts. >>>> Here is the procedure I'm using to renew the certificates. One of the >>>> tricky things is to not have the certificate system working when >>>> certmonger is started so that it doesn't renew a certificate on >>>> startup that might not be one I have changed the request file for >>>> (other certificates have similar problems with bad subject CN and stop >>>> the certificate system.) >>>> >>>> I've found it convenient to keep reinitializing the log files because >>>> they get very confusing when the clock keeps getting set back. >>>> >>>> The request number has changed since we did the stop-tracking / >>>> start-tracking. >>>> >>>> Roderick >>>> >>>> ipactl stop >>>> >>>> # Set clock back: >>>> systemctl stop ntpd >>>> timedatectl set-time "2017-10-23 00:00:00" >>>> date >>>> >>>> #Stop certificate renewals the systemd way >>>> systemctl stop certmonger >>>> >>>> # Sort out certmonger log >>>> mv /var/log/certmonger.log /var/log/certmonger.log-$(date >>>> +%Y%m%d:%H:%M) >>>> >>>> # ****** Copy in the fixed certmonger request >>>> \cp /root/20161124081302.ocsp_backup >>>> /var/lib/certmonger/requests/20161124081302 >>>> >>>> >>>> # In another window >>>> certmonger -n -d 9 2>&1 | tee /var/log/certmonger.log >>>> >>>> # In the original window >>>> # Sort out dogtag log >>>> mv /var/log/pki/pki-tomcat/ca/debug >>>> /var/log/pki/pki-tomcat/ca/debug-$(date +%Y%m%d:%H:%M).log >>>> touch /var/log/pki/pki-tomcat/ca/debug >>>> chown pkiuser:pkiuser /var/log/pki/pki-tomcat/ca/debug >>>> >>>> mv /var/log/pki/pki-tomcat/ca/selftests.log >>>> /var/log/pki/pki-tomcat/ca/selftests.log-$(date +%Y%m%d:%H:%M) >>>> touch /var/log/pki/pki-tomcat/ca/selftests.log >>>> chown pkiuser:pkiuser /var/log/pki/pki-tomcat/ca/selftests.log >>>> >>>> \cp /var/tmp/rmj/etc/httpd/alias/cert8.db /etc/httpd/alias/cert8.db >>>> \cp /var/tmp/rmj/etc/httpd/alias/key3.db /etc/httpd/alias/key3.db >>>> \cp /var/tmp/rmj/etc/pki/pki-tomcat/alias/cert8.db >>>> /etc/pki/pki-tomcat/alias/cert8.db >>>> \cp /var/tmp/rmj/etc/pki/pki-tomcat/alias/key3.db >>>> /etc/pki/pki-tomcat/alias/key3.db >>>> >>>> \cp /var/tmp/rmj/etc/pki/pki-tomcat/ca/CS.cfg >>>> /etc/pki/pki-tomcat/ca/CS.cfg >>>> >>>> # Fix up certificate permissions and check all is ok >>>> certutil -M -n "caSigningCert cert-pki-ca" -d >>>> /etc/pki/pki-tomcat/alias -t CTu,Cu,Cu >>>> certutil -L -d /etc/pki/pki-tomcat/alias >>>> certutil -K -d /etc/pki/pki-tomcat/alias >>>> <pin> >>>> >>>> # Fix dogtag so it starts >>>> pki-server subsystem-enable ca > >>>> # Start IdM services >>>> >>>> ipactl start >>>> ipactl status >>>> >>>> #Resubmit certificate ocsp >>>> date;getcert resubmit -i 20161124081302 >>> >>> Hi Rob >>> >>> Does it look like there is anything I should be doing differently in >>> this command sequence to try to get the certificate renewed correctly? >>> >>> I'm starting to wonder whether I should look at alternative strategies >>> for recovering the freeipa servers if the certificates won't renew >>> correctly. Do you have any ideas on this please? >>> >> >> This looks reasonable. Have you tried stop-tracking and start-tracking I >> suggested? > > Yes,I tried the stop-tracking / start-tracking. Same result, bad Subject > CN. > >> >> I'm still baffled how the name(s) are getting mixed up. > > Indeed, something is going round changing the subject. In the dogtag > debug log is: > [23/Oct/2017:00:13:52][http-bio-8080-exec-9]: processRenewal: > origNotAfter =Wed Oct 25 13:24:01 BST 2017 > [23/Oct/2017:00:13:52][http-bio-8080-exec-9]: processRenewal: orig subj > dn =CN=OCSP Subsystem,O=AST.CAM.AC.UK > > and then very shortly afterwards there is a csr listed that decodes to > have the bad Subject CN. > > The listed csr doesn't match any I have been able to find on the system, > so something must be going round and changing it. > >> >> Something else you might want to try would be to move all the other >> requests out of the way in case there is some sort of memory corruption >> causing the hostname to get in there somehow. > > Thanks for the suggestion which I have now tried. Same result I'm afraid. > > I've now been battling this issue since the beginning of November. > > I'm wondering whether, just to get our IPA system fully operational > again, whether we might be able to add the correct CN into a Subject > Alternative name? > > Does this sound like a possible way to at least get all the IPA services > started properly? > > Do you think it would cause further problems down the line? > > Would you be able to advise how to get the certificates to have the > correct CN in the Subject Alternative Name. > > Maybe there are some other tricks we could use just to get going again. > > Can you advise please? >
I'm really stumped here. Do you have the CA installed on any other masters? You might try setting it as the renewal master and trying the renewals there instead. rob _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org