I got tomcat-pki to start, but ipa-certupdate gets the following error:
CERTIFICATE_VERIFY_FAILED
Is there a way to get certupdate to ignore the cert? The cert is in date,
but doesn't seem to be trusted I think?
Thomas
On Thu, Aug 9, 2018 at 10:04 PM Thomas Letherby <xrs444(a)xrs444.net> wrote:
I'm guessing I've hit the end of the line here, so I'll
have to just
reinstall the servers and start from scratch, there's very little config,
so it shouldn't be to hard to rebuild.
For the client servers, can i just unjoin then join them to the new
domain, or do I need to clear out stuff first? For a client machine that
has FreeIPA users, will the home folders be picked up by the new user, or
should I backup and restore them later?
Of course if anyone has a better idea I'm all ears!
Thomas
On Fri, Aug 3, 2018 at 5:45 PM Thomas Letherby <xrs444(a)xrs444.net> wrote:
> I tried using the instructions here, given that the server certs are out
> of step with the CA cert:
>
>
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
> But when I go to submit the request using certutil as per here:
>
>
>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
> I get this error:
>
> ipa: ERROR: cannot connect to 'any of the configured servers'
>
> This is probably because Tomcat is failing to start. I've set HTTPD to
> ignore cert errors, and it's set to WARN in LDAP.
>
> The Tomcat error is:
>
> Internal Database Error encountered: Could not connect to LDAP server
> host
xipa1.i.domain.net port 636 Error netscape.ldap.LDAPException:
> Authentication failed (48)
>
> Seem to be playing chase the error here, but if I can get Tomcat to
> start, I should be able to replace the certificates and be back up and
> running.
>
> Any idea how to do that?
>
> Thanks all!
>
> Thomas
>
>
> On Wed, Aug 1, 2018 at 8:35 PM Thomas Letherby <xrs444(a)xrs444.net> wrote:
>
>> 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 <xrs444(a)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 <rcritten(a)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
<xrs444(a)xrs444.net
>>>> > <mailto:xrs444@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 <
>>>> rcritten(a)redhat.com
>>>> > <mailto:rcritten@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.trefois(a)uni.lu <mailto:
>>>> christophe.trefois(a)uni.lu>
>>>> > <mailto:christophe.trefois@uni.lu
>>>> > <mailto:christophe.trefois@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
>>>> > <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
>>>> > >> <ftweedal(a)redhat.com
<mailto:ftweedal@redhat.com>
>>>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@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
>>>> > >> <ftweedal(a)redhat.com
<mailto:ftweedal@redhat.com>
>>>> > <mailto:ftweedal@redhat.com
<mailto:ftweedal@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
>>>> > >> <rcritten(a)redhat.com
<mailto:rcritten@redhat.com>
>>>> > <mailto:rcritten@redhat.com
<mailto:rcritten@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 <
>>>> > >> > > flo(a)redhat.com
<mailto:flo@redhat.com>
>>>> > <mailto:flo@redhat.com <mailto:flo@redhat.com>>
>>>> > >> > > > > >
<mailto:flo@redhat.com
>>>> > <mailto:flo@redhat.com> <mailto:flo@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>>
>>>> > >> > > > > >
<mailto:xrs444@xrs444.net
>>>> > <mailto:xrs444@xrs444.net>
>>>> > >> <mailto:xrs444@xrs444.net <mailto:
>>>> xrs444(a)xrs444.net>>>
>>>> > >> > > > > > >
<mailto:xrs444@xrs444.net
>>>> > <mailto:xrs444@xrs444.net>
>>>> > >> <mailto:xrs444@xrs444.net
>>>> > <mailto:xrs444@xrs444.net>>
<mailto:xrs444@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@redhat.com>>
<mailto:ftweedal@redhat.com
>>>> > <mailto:ftweedal@redhat.com>
>>>> > >> <mailto:ftweedal@redhat.com
>>>> > <mailto:ftweedal@redhat.com>>>
>>>> > >> > > > > > >
<mailto:ftweedal@redhat.com
>>>> > <mailto:ftweedal@redhat.com>
>>>> > >> <mailto:ftweedal@redhat.com
>>>> > <mailto:ftweedal@redhat.com>>
<mailto:ftweedal@redhat.com
>>>> > <mailto:ftweedal@redhat.com>
>>>> > >> <mailto:ftweedal@redhat.com
>>>> > <mailto:ftweedal@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>>
>>>> > >> > > > > >
>>>> > <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-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>>
>>>> > >> > > > > >
>>>> > >> <mailto:
>>>> 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>>>
>>>> > >> > > > > > >
>>>> > >> <mailto:
>>>> 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>>
>>>> > >> > > > > >
>>>> > >> <mailto:
>>>> 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>
>>>> > >>
<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-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>>
>>>> > >> > > > > >
>>>
>>>