Just to add, getcert seems to think they're all up to date:
getcert list | grep expires
expires: 2019-06-16 04:38:58 UTC
expires: 2020-06-05 01:24:55 UTC
expires: 2020-06-05 01:29:28 UTC
expires: 2020-06-05 01:32:01 UTC
expires: 2038-06-17 09:06:38 UTC
expires: 2020-06-05 01:34:31 UTC
expires: 2020-06-01 00:43:22 UTC
expires: 2020-06-15 04:08:47 UTC
expires: 2020-06-16 03:20:19 UTC
ipa-getcert list | grep expires
expires: 2020-06-15 04:08:47 UTC
expires: 2020-06-16 03:20:19 UTC
Thomas
On Wed, Jul 11, 2018 at 5:33 PM Thomas Letherby <xrs444(a)xrs444.net> 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 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?
Thanks,
Thomas
On Mon, Jul 9, 2018 at 8:05 AM Christophe TREFOIS <
christophe.trefois(a)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(a)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/> IPA CA
>
> certutil -d /etc/httpd/alias -L
> Signing-Cert
>
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/> 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 <ftweedal(a)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 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 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
<ftweedal(a)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/> IPA CA
>> CT,C,C
>> > > >
>> > > >
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 <
>> rcritten(a)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/>>
>> > > 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> 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/>> 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/>> 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
<
>> > > flo(a)redhat.com
>> > > > > > <mailto:flo@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
<
>> > > xrs444(a)xrs444.net
>> > > > > > <mailto:xrs444@xrs444.net>
>> > > > > > > <mailto:xrs444@xrs444.net
<mailto:xrs444@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
>> > > > > > <ftweedal(a)redhat.com
<mailto:ftweedal@redhat.com>
>> > > > > > > <mailto:ftweedal@redhat.com <mailto:
>> ftweedal(a)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(a)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-leave(a)lists.fedorahosted.org
>> > > > > >
<mailto:freeipa-users-leave@lists.fedorahosted.org>
>> > > > > > > <mailto:
>> freeipa-users-leave(a)lists.fedorahosted.org
>> > > > > >
<mailto:freeipa-users-leave@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.fedorah...
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
_______________________________________________
>> > > > > > > FreeIPA-users mailing list --
>> > > freeipa-users(a)lists.fedorahosted.org
>> > > > > > <mailto:freeipa-users@lists.fedorahosted.org>
>> > > > > > > To unsubscribe send an email to
>> > > > > > freeipa-users-leave(a)lists.fedorahosted.org
>> > > > > >
<mailto:freeipa-users-leave@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.fedorah...
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > _______________________________________________
>> > > > > > FreeIPA-users mailing list --
>> freeipa-users(a)lists.fedorahosted.org
>> > > > > > To unsubscribe send an email to
>> > > > > freeipa-users-leave(a)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.fedorah...
>> > > > > >
>> > > > >
>> > > > >
>> > >
>>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)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.fedorah...
>
>
>