[Freeipa-users] healthcheck errors

[Prasun Gera via FreeIPA-users]

I'm seeing the following two errors on running ipahealthcheck. This is on
an up to date RHEL 8.3 system in a 2 server topology with self signed CA.

DOMAIN.COM IPA CA not found, assuming 3rd party
DOMAIN.COM IPA CA not found, assuming 3rd party
[
  {
"source": "pki.server.healthcheck.meta.csconfig",
"check": "CADogtagCertsConfigCheck",
"result": "ERROR",
"uuid": "da820035-6955-436f-9bf5-bde578b27920",
"when": "20201221130025Z",
"duration": "0.172261",
"kw": {
  "key": "ca_signing",
  "nickname": "caSigningCert cert-pki-ca",
  "directive": "ca.signing.cert",
  "configfile": "/var/lib/pki/pki-tomcat/ca/conf/CS.cfg",
  "msg": "Certificate 'caSigningCert cert-pki-ca' does not match the
value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg"
}
  },
  {
"source": "ipahealthcheck.ipa.certs",
"check": "IPACertTracking",
"result": "ERROR",
"uuid": "cfba0bf1-4e4b-40d6-9d26-455bab9c9057",
"when": "20201221130027Z",
"duration": "0.307626",
"kw": {
  "key": "cert-database=/etc/pki/pki-tomcat/alias,
cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent,
cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert
\"caSigningCert cert-pki-ca\", template-profile=caCACert",
  "msg": "Missing tracking for cert-database=/etc/pki/pki-tomcat/alias,
cert-nickname=caSigningCert cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent,
cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert
\"caSigningCert cert-pki-ca\", template-profile=caCACert"
}
  },
...
]


   1. This is with a self-signed CA. So I don't know why it has that
   assuming 3rd party message.
   2. I think this has something to do with the fact
   that /etc/pki/pki-tomcat/alias/ has two certs under the nickname
   of "caSigningCert cert-pki-ca", (one for each of the masters I presume),
   but somehow only 1 cert is tracked in other parts of the
   infrastructure. /var/lib/pki/pki-tomcat/ca/conf/CS.cfg lists a single
   certificate under ca.signing.cert and there is also a single entry in LDAP
   (which is the same as CS.cfg). Is something broken in my setup ?

Thanks,
Prasun
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: healthcheck errors

[Prasun Gera via FreeIPA-users]

Thanks, Rob. Here are the outputs:

certutil -L -d /etc/pki/pki-tomcat/alias/

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
caSigningCert cert-pki-caCTu,Cu,Cu
DOMAIN.COM IPA CACTu,Cu,Cu

getcert list -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert cert-pki-ca'
Number of certificates and requests being tracked: 9.
Request ID '20201221144720':
status: MONITORING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=DOMAIN.COM
subject: CN=Certificate Authority,O=DOMAIN.COM
expires: 2040-12-21 06:51:45 EST
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
profile: caCACert
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert
cert-pki-ca"
track: yes
auto-renew: yes

The other thing I tried was ipa-server-upgrade, which does resolve the 2nd
failure. It adds the missing tracking. However, if I run ipa-certupdate
after that, the error appears again. It appears that ipa-certupdate clears
it. One thing worth mentioning is that I had run ipa-cacert-manage renew
earlier. Is this related to it somehow ? I'm not entirely sure why there
are two certificates with two serial numbers. They both have the same
validity dates, only different times. One is off by 1 hour.

On Mon, Dec 21, 2020 at 10:53 AM Rob Crittenden  wrote:

> Prasun Gera via FreeIPA-users wrote:
> > I'm seeing the following two errors on running ipahealthcheck. This is
> > on an up to date RHEL 8.3 system in a 2 server topology with self signed
> CA.
> >
> > DOMAIN.COM <http://DOMAIN.COM> IPA CA not found, assuming 3rd party
> > DOMAIN.COM <http://DOMAIN.COM> IPA CA not found, assuming 3rd party
>
> I'd need to see the output of certutil -L -d /etc/pki/pki-tomcat/alias/
>
> An expected nickname was not present either in the database or in CS.cfg.
>
> > [
> >   {
> > "source": "pki.server.healthcheck.meta.csconfig",
> > "check": "CADogtagCertsConfigCheck",
> > "result": "ERROR",
> > "uuid": "da820035-6955-436f-9bf5-bde578b27920",
> > "when": "20201221130025Z",
> > "duration": "0.172261",
> > "kw": {
> >   "key": "ca_signing",
> >   "nickname": "caSigningCert cert-pki-ca",
> >   "directive": "ca.signing.cert",
> >   "configfile": "/var/lib/pki/pki-tomcat/ca/conf/CS.cfg",
> >   "msg": "Certificate 'caSigningCert cert-pki-ca' does not match the
> > value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg"
> > }
> >   },
>
> You may be right, perhaps the dogtag checker doesn't check all values of
> the certificate. I'd suggest opening an issue at
> https://github.com/dogtagpki/pki
>
> >   {
> > "source": "ipahealthcheck.ipa.certs",
> > "check": "IPACertTracking",
> > "result": "ERROR",
> > "uuid": "cfba0bf1-4e4b-40d6-9d26-455bab9c9057",
> > "when": "20201221130027Z",
> > "duration": "0.307626",
> > "kw": {
> >   "key": "cert-database=/etc/pki/pki-tomcat/alias,
> > cert-nickname=caSigningCert cert-pki-ca,
> > ca-name=dogtag-ipa-ca-renew-agent,
> > cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
> > cert-postsave-command=/usr/libexec/ipa/certmonger/renew_ca_cert
> > \"caSigningCert cert-pki-ca\", template-profile=caCACert",
> >   "msg": "Missing tracking for
> > cert-database=/etc/pki/pki-tomcat/alias, cert-nickname=caSigningCert
> > cert-pki-ca, ca-name=dogtag-ipa-ca-renew-agent,
> > cert-presave-command=/usr/libexec/ipa/certmonger/stop_pkicad,
> > cert-postsave-command=/us

[Freeipa-users] Re: healthcheck errors

[Prasun Gera via FreeIPA-users]

Renaming creates a duplicate. There was already a 'caSigningCert
cert-pki-ca' present in the db. Now it shows two entries with the same
nick. This shouldn't happen, right ? Should I delete 'DOMAIN.COM
<http://domain.com/> IPA CA' instead (after restoring
/etc/pki/pki-tomcat/alias/)? It had the same contents as 'caSigningCert
cert-pki-ca'. Here is what it looks like:

certutil -L -d /etc/pki/pki-tomcat/alias/

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca  u,u,u
subsystemCert cert-pki-cau,u,u
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca  u,u,u
caSigningCert cert-pki-caCTu,Cu,Cu
caSigningCert cert-pki-caCTu,Cu,Cu

On Tue, Dec 22, 2020 at 10:22 AM Rob Crittenden  wrote:

> Prasun Gera wrote:
> > Thanks, Rob. Here are the outputs:
> >
> > certutil -L -d /etc/pki/pki-tomcat/alias/
> >
> > Certificate Nickname Trust
> > Attributes
> >
> >  SSL,S/MIME,JAR/XPI
> >
> > Server-Cert cert-pki-ca  u,u,u
> > subsystemCert cert-pki-cau,u,u
> > auditSigningCert cert-pki-ca u,u,Pu
> > ocspSigningCert cert-pki-ca  u,u,u
> > caSigningCert cert-pki-caCTu,Cu,Cu
> > DOMAIN.COM <http://DOMAIN.COM> IPA CA
> >  CTu,Cu,Cu
>
> That identifies one problem. The nickname that is currently 'DOMAIN.COM
> IPA CA' should be 'caSigningCert cert-pki-ca'.
>
> To fix:
>
> 1. ipa cert-show 1 (output doesn't matter just shouldn't be an error)
> 2. ipactl stop
> 3. backup /etc/pki/pki-tomcat/alias/* someplace safe
> 4. certutil --rename -d /etc/pki/pki-tomcat/alias/ --new-n
> 'caSigningCert cert-pki-ca' -n 'DOMAIN.COM IPA CA'
> 5. ipactl start
> 6. ipa cert-show 1 (again, should return a cert)
>
> > getcert list -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert cert-pki-ca'
> > Number of certificates and requests being tracked: 9.
> > Request ID '20201221144720':
> > status: MONITORING
> > stuck: no
> > key pair storage:
> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> > cert-pki-ca',token='NSS Certificate DB',pin set
> > certificate:
> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> > cert-pki-ca',token='NSS Certificate DB'
> > CA: dogtag-ipa-ca-renew-agent
> > issuer: CN=Certificate Authority,O=DOMAIN.COM <http://DOMAIN.COM>
> > subject: CN=Certificate Authority,O=DOMAIN.COM <http://DOMAIN.COM>
> > expires: 2040-12-21 06:51:45 EST
> > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> > profile: caCACert
> > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> > "caSigningCert cert-pki-ca"
> > track: yes
> > auto-renew: yes
> >
> > The other thing I tried was ipa-server-upgrade, which does resolve the
> > 2nd failure. It adds the missing tracking. However, if I run
> > ipa-certupdate after that, the error appears again. It appears that
> > ipa-certupdate clears it. One thing worth mentioning is that I had
> > run ipa-cacert-manage renew earlier. Is this related to it somehow ? I'm
> > not entirely sure why there are two certificates with two serial
> > numbers. They both have the same validity dates, only different times.
> > One is off by 1 hour.
>
> Interesting. I'm not sure why ipa-certupdate would affect the certmonger
> tracking. This may also be failing due to the nickname.
>
> ipa-cacert-manage renews the CA cert. So you renewed your CA, which is
> unnecessary this far ahead of expiration. It definitely explains the
> dogtag healthcheck issue.
>
> Doing the rename may fix the ipa-certupdate issue.
>
> rob
>
> >
> > On Mon, Dec 21, 2020 at 10:53 AM Rob Crittenden  > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Prasun Gera via FreeIPA-users wrote:
> > > I'm seeing the following two errors on running ipahealthcheck.
> This is
> > > on an up to date RHEL 8.3 system in a 2 server topology with self
> > signed CA.
> > >
&g

[Freeipa-users] Re: healthcheck errors

[Prasun Gera via FreeIPA-users]

Thanks. That has fixed a part of the problem. I did the rename followed by
ipa-certupdate, which clears the duplicate nickname. It also shows only a
single value under the nickname now. I don't see the CS.cfg error anymore.
However, something is still not right with certupdate and tracking. After
certupdate, I get the tracking error in healthcheck. If I do
ipa-server-upgrade, it fixes the tracking and also prints this:
"Missing or incorrect tracking request for certificates:
  /etc/pki/pki-tomcat/alias:caSigningCert cert-pki-ca"
after which healthcheck reports no errors. Running certupdate brings the
error back.

On Wed, Dec 23, 2020 at 10:04 AM Rob Crittenden  wrote:

> Prasun Gera via FreeIPA-users wrote:
> > Renaming creates a duplicate. There was already a 'caSigningCert
> > cert-pki-ca' present in the db. Now it shows two entries with the same
> > nick. This shouldn't happen, right ? Should I delete 'DOMAIN.COM
> > <http://domain.com/> IPA CA' instead (after restoring
> > /etc/pki/pki-tomcat/alias/)? It had the same contents as 'caSigningCert
> > cert-pki-ca'. Here is what it looks like:
> >
> > certutil -L -d /etc/pki/pki-tomcat/alias/
> >
> > Certificate Nickname Trust
> > Attributes
> >
> >  SSL,S/MIME,JAR/XPI
> >
> > Server-Cert cert-pki-ca  u,u,u
> > subsystemCert cert-pki-cau,u,u
> > auditSigningCert cert-pki-ca u,u,Pu
> > ocspSigningCert cert-pki-ca  u,u,u
> > caSigningCert cert-pki-caCTu,Cu,Cu
> > caSigningCert cert-pki-caCTu,Cu,Cu
>
> I think that ipa-certupdate was adding the other nickname. I believe
> this will prevent that.
>
> rob
>
> >
> > On Tue, Dec 22, 2020 at 10:22 AM Rob Crittenden  > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Prasun Gera wrote:
> > > Thanks, Rob. Here are the outputs:
> > >
> > > certutil -L -d /etc/pki/pki-tomcat/alias/
> > >
> > > Certificate Nickname Trust
> > > Attributes
> > >
> > >  SSL,S/MIME,JAR/XPI
> > >
> > > Server-Cert cert-pki-ca  u,u,u
> > > subsystemCert cert-pki-cau,u,u
> > > auditSigningCert cert-pki-ca u,u,Pu
> > > ocspSigningCert cert-pki-ca  u,u,u
> > > caSigningCert cert-pki-ca
>  CTu,Cu,Cu
> > > DOMAIN.COM <http://DOMAIN.COM> <http://DOMAIN.COM> IPA CA
> >
> > >  CTu,Cu,Cu
> >
> > That identifies one problem. The nickname that is currently
> > 'DOMAIN.COM <http://DOMAIN.COM>
> > IPA CA' should be 'caSigningCert cert-pki-ca'.
> >
> > To fix:
> >
> > 1. ipa cert-show 1 (output doesn't matter just shouldn't be an error)
> > 2. ipactl stop
> > 3. backup /etc/pki/pki-tomcat/alias/* someplace safe
> > 4. certutil --rename -d /etc/pki/pki-tomcat/alias/ --new-n
> > 'caSigningCert cert-pki-ca' -n 'DOMAIN.COM <http://DOMAIN.COM> IPA
> CA'
> > 5. ipactl start
> > 6. ipa cert-show 1 (again, should return a cert)
> >
> > > getcert list -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert
> > cert-pki-ca'
> > > Number of certificates and requests being tracked: 9.
> > > Request ID '20201221144720':
> > > status: MONITORING
> > > stuck: no
> > > key pair storage:
> > >
> >
>  type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> > > cert-pki-ca',token='NSS Certificate DB',pin set
> > > certificate:
> > >
> >
>  type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> > > cert-pki-ca',token='NSS Certificate DB'
> > > CA: dogtag-ipa-ca-renew-agent
> > > issuer: CN=Certificate Authority,O=DOMAIN.COM <http://DOMAIN.COM>
> > <http://DOMAIN.COM>
> > > subject: CN=Certificate Authority,O=DOMAIN.COM <http://DOMAIN.COM>
> > <http://DOMAIN.COM>
> > > expires: 2040-12-21 06:51:45 EST
> > > key usage: dig

[Freeipa-users] Re: healthcheck errors

[Prasun Gera via FreeIPA-users]

Thanks, Rob!

On Tue, Jan 5, 2021 at 10:01 AM Rob Crittenden  wrote:

> Prasun Gera via FreeIPA-users wrote:
> > Thanks. That has fixed a part of the problem. I did the rename followed
> > by ipa-certupdate, which clears the duplicate nickname. It also shows
> > only a single value under the nickname now. I don't see the CS.cfg error
> > anymore. However, something is still not right with certupdate and
> > tracking. After certupdate, I get the tracking error in healthcheck. If
> > I do ipa-server-upgrade, it fixes the tracking and also prints this:
> > "Missing or incorrect tracking request for certificates:
> >   /etc/pki/pki-tomcat/alias:caSigningCert cert-pki-ca"
> > after which healthcheck reports no errors. Running certupdate brings the
> > error back.
>
> To close the loop on this I was able to reproduce this and opened
> https://pagure.io/freeipa/issue/8644 . A PR to fix this has been
> submitted upstream.
>
> rob
>
> >
> > On Wed, Dec 23, 2020 at 10:04 AM Rob Crittenden  > <mailto:rcrit...@redhat.com>> wrote:
> >
> > Prasun Gera via FreeIPA-users wrote:
> > > Renaming creates a duplicate. There was already a 'caSigningCert
> > > cert-pki-ca' present in the db. Now it shows two entries with the
> same
> > > nick. This shouldn't happen, right ? Should I delete 'DOMAIN.COM
> > <http://DOMAIN.COM>
> > > <http://domain.com/> IPA CA' instead (after restoring
> > > /etc/pki/pki-tomcat/alias/)? It had the same contents
> > as 'caSigningCert
> > > cert-pki-ca'. Here is what it looks like:
> > >
> > > certutil -L -d /etc/pki/pki-tomcat/alias/
> > >
> > > Certificate Nickname Trust
> > > Attributes
> > >
> > >  SSL,S/MIME,JAR/XPI
> > >
> > > Server-Cert cert-pki-ca  u,u,u
> > > subsystemCert cert-pki-cau,u,u
> > > auditSigningCert cert-pki-ca u,u,Pu
> > > ocspSigningCert cert-pki-ca  u,u,u
> > > caSigningCert cert-pki-ca
>  CTu,Cu,Cu
> > > caSigningCert cert-pki-ca
>  CTu,Cu,Cu
> >
> > I think that ipa-certupdate was adding the other nickname. I believe
> > this will prevent that.
> >
> > rob
> >
> > >
> > > On Tue, Dec 22, 2020 at 10:22 AM Rob Crittenden
> > mailto:rcrit...@redhat.com>
> > > <mailto:rcrit...@redhat.com <mailto:rcrit...@redhat.com>>> wrote:
> > >
> > > Prasun Gera wrote:
> > > > Thanks, Rob. Here are the outputs:
> > > >
> > > > certutil -L -d /etc/pki/pki-tomcat/alias/
> > > >
> > > > Certificate Nickname
> > Trust
> > > > Attributes
> > > >
> > > >  SSL,S/MIME,JAR/XPI
> > > >
> > > > Server-Cert cert-pki-ca
> >  u,u,u
> > > > subsystemCert cert-pki-ca
> >  u,u,u
> > > > auditSigningCert cert-pki-ca
> > u,u,Pu
> > > > ocspSigningCert cert-pki-ca
> >  u,u,u
> > > > caSigningCert cert-pki-ca
> >  CTu,Cu,Cu
> > > > DOMAIN.COM <http://DOMAIN.COM> <http://DOMAIN.COM>
> > <http://DOMAIN.COM> IPA CA
> > >
> > > >  CTu,Cu,Cu
> > >
> > > That identifies one problem. The nickname that is currently
> > > 'DOMAIN.COM <http://DOMAIN.COM> <http://DOMAIN.COM>
> > > IPA CA' should be 'caSigningCert cert-pki-ca'.
> > >
> > > To fix:
> > >
> > > 1. ipa cert-show 1 (output doesn't matter just shouldn't be an
> > error)
> > > 2. ipactl stop
> > > 3. backup /etc/pki/pki-tomcat/alias/* someplace safe
> > > 4. certutil --rename -d /etc/pki/pki-tomcat/alias/ --new-n
> > > 'caSigningCert cert-pki-ca' -n 'DOMAIN.COM <http://DOMAIN.COM>
> > <http://DOMAIN.COM> IPA CA'
> > > 5. ipactl start
> > > 6. ipa cert-show 1 (again, should return a cert)
> > >
> > > > getcert li

[Freeipa-users] Re: User login

[Prasun Gera via FreeIPA-users]

That config gets overwritten on upgrades though. Can freeipa expose this as
a knob rather than users modifying config files directly ?

On Wed, Sep 22, 2021 at 10:03 PM Alexander Bokovoy via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> On ke, 22 syys 2021, Cutright, Jacob via FreeIPA-users wrote:
> >Hello,
> >
> >I can also confirm this is a normal occurrence on Windows while using
> >Chrome and Edge. Firefox, however, does not do this. It is a bit confusing
> >for new users of IPA as they will generally treat it as a login prompt,
> >although it doesn't do anything for them. I have been curious about this
> >prompt, but haven't had a chance to look into it yet.
>
> This is a bug in Windows browsers based on Chrome engine. It is known
> for years and Chrome developers refused to fix it.
>
> One thing you can do is to follow a recipe in
> https://bugzilla.redhat.com/show_bug.cgi?id=1309041
>
> ...
> 
>AuthType GSSAPI
>AuthName "Kerberos Login"
>BrowserMatch Windows gssapi-no-negotiate
> ...
>
>
> Perhaps, we need to finally add this line to the default IPA
> configuration as per https://pagure.io/freeipa/issue/5614
>
> >
> >
> >On Wed, Sep 22, 2021, 3:51 PM Sam Morris via FreeIPA-users <
> >freeipa-users@lists.fedorahosted.org> wrote:
> >
> >> > Florence Renaud via FreeIPA-users wrote:
> >> > IIRC some browsers, notably on Windows, when the initial GSSAPI
> >> > handshake fails because there is no ticket, may either throw an error
> >> > because they are trying NTLM auth or don't understand the basic
> fallback.
> >> >
> >> > What browser(s) are you seeing the issue on?
> >>
> >> I see this on Windows 10 Home with Chrome 93.0.4577.82 (and older
> >> versions).
> >>
> >> I get two login prompts - the first is caused by a POST to
> >> /ipa/session/json resulting in a 401.
> >>
> >> The second is caused by a GET for /ipa/session/login_kerberos?_= >> timestamp>.
> >>
> >> Both responses have the WWW-Authenticate: Negotiate header.
> >>
> >> I happen to have MIT Kerberos for Windows installed--that may or may not
> >> be relevant. I've not (as far as I remember) configured Chrome to try to
> >> use SPNEGO to talk to my IPA servers so this may not be relevant.
> >>
> >> --
> >> Sam Morris 
> >> PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
> >> ___
> >> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >>
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> >> Do not reply to spam on the list, report it:
> >> https://pagure.io/fedora-infrastructure
> >>
>
>
>
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland
> ___
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Chrome 58 - CN for IPA management console to include SANs

[Prasun Gera via FreeIPA-users]

I posted this in the earlier thread, but didn't get a response. I was able
to fix this on the master, but "getcert list -d /etc/httpd/alias -n
"Server-Cert" on the replica doesn't return anything. Are the replica's SSL
certs handled differently ?

On Tue, May 23, 2017 at 3:08 PM, Alexander Bokovoy via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> On ti, 23 touko 2017, Jake via FreeIPA-users wrote:
>
>> Worked! Thanks!
>>
>> I Suppose there isn't a way to get the output of getcert as
>> JSON/object? I would prefer to do this with ansible =)
>>
> Not directly. You may want to explore D-Bus interface provided by
> certmonger.
>
>
>> Also, "sudo systemctl restart httpd" post renewal (looks like the hooks
>> aren't configured for the cert renewal to restart dependent services.)
>>
> For httpd certs configured by IPA install, there is a script that
> restarts httpd, as can be seen in 'post-save command' below:
>
> Request ID '20170215074615':
> status: MONITORING
> stuck: no
> key pair storage: type=NSSDB,location='/etc/http
> d/alias',nickname='Server-Cert',token='NSS Certificate
> DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> certificate: type=NSSDB,location='/etc/http
> d/alias',nickname='Server-Cert',token='NSS Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=EXAMPLE.COM
> subject: CN=ipa.example.com,O=EXAMPLE.COM
> expires: 2019-01-29 18:11:46 UTC
> dns: ipa.example.com
> key usage: digitalSignature,nonRepudiatio
> n,keyEncipherment,dataEncipherment
> eku: id-kp-serverAuth,id-kp-clientAuth
> pre-save command:   post-save command:
> /usr/libexec/ipa/certmonger/restart_httpd
> track: yes
> auto-renew: yes
>
>
> --
> / Alexander Bokovoy
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to 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

[Freeipa-users] Re: Chrome 58 - CN for IPA management console to include SANs

[Prasun Gera via FreeIPA-users]

I see the replica listed under services idm's web-ui. It appears as "
HTTP/replica@DOMAIN". Is this normal ? I'm not sure if it's being tracked
for auto-renewal or if it was issued as a one time cert during setup. What
would be the steps to fix this ?

On Wed, May 24, 2017 at 12:00 AM, Alexander Bokovoy 
wrote:

> On ti, 23 touko 2017, Prasun Gera via FreeIPA-users wrote:
>
>> I posted this in the earlier thread, but didn't get a response. I was able
>> to fix this on the master, but "getcert list -d /etc/httpd/alias -n
>> "Server-Cert" on the replica doesn't return anything. Are the replica's
>> SSL
>> certs handled differently ?
>>
> I don't think there is any difference, not at least code-wise, for how
> HTTP service certificate is tracked in the case of IPA CA.
>
> In case of a replica promotion a request to issue HTTP service
> certificate is routed to the original IPA CA master (because the one we
> will have on the replica itself is not yet here). Either way, certmonger
> is set to track the same Server-Cert certificate in /etc/httpd/alias
> during server upgrade process that is one of the last steps when replica
> is installed.
>
> --
> / Alexander Bokovoy
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: autofs.service on NFS clients and servers

[Prasun Gera via FreeIPA-users]

One easy way to resolve your issues it to use different names for the
export location and the mount location. Your export location is handled by
fstab, whereas your mount location is handled by autofs. For example, your
have server1 with /export_data1 and server2 with /export_data2 mounted via
fstab. NFS + autofs will mount them as /data1 and /data2 on all the clients
including the NFS servers. Does this work for you ?

On Sun, Jul 2, 2017 at 1:58 PM, Petros Triantafyllidis via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi all,
>   I am very new to IPA and still a bit before going into production, so
> apologies in advance.
>
> The plan is to have a number of servers that each one shares a space via
> kerberized nfs4 to the others, which makes all of them NFS clients and
> servers at the same time. On my attempt to setup automount globally via IdM
> and sssd, I realized that when a machine is configured as nfs server, it
> needs autofs.service to be stopped in order to access it's local shares
> mounted via fstab. If I use /etc/auto.master to mount the local shares
> instead of fstab, then autofs.service may (actually must) run and
> everything works properly but, doing so, I don't have the advantage of one
> central configuration location any more.
> The preferred scenario for each server would be to mount its local shares
> via fstab and the remote shares via sssd automount. Am I missing something?
>
> Thanks in advance,
> Petros
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to 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

[Freeipa-users] Re: autofs.service on NFS clients and servers

[Prasun Gera via FreeIPA-users]

The only thing I would be interested in knowing is if there is a
performance penalty to mounting NFS locally. Ideally, it should be smart
enough to know that, but I'm not sure if it is.

On 14 Jul 2017 6:08 pm, "Petros Triantafyllidis"  wrote:

> Thanks a lot for replying,
>   Yes, your suggestion is working. Doesn't seem that elegant though, since
> a partition is mounted several times. However it's practical and I can't
> figure out how else it could be done.
> From mount stats, the first two are from fstab mount and appears only on
> NFS server, while the third is the automount and appears on all NFS clients
> (NFS server included)
>
> /dev/sdb1 on /export/data1 type xfs (rw,relatime,attr2,inode64,noquota)
> /dev/sdb1 on /data1 type xfs (rw,relatime,attr2,inode64,noquota)
> auto.direct on /data1 type autofs (rw,relatime,fd=18,pgrp=34091,
> timeout=300,minproto=5,maxproto=5,direct)
>
> Thanks a lot,
> Petros
>
> On 07/12/2017 01:11 AM, Prasun Gera via FreeIPA-users wrote:
>
> One easy way to resolve your issues it to use different names for the
> export location and the mount location. Your export location is handled by
> fstab, whereas your mount location is handled by autofs. For example, your
> have server1 with /export_data1 and server2 with /export_data2 mounted via
> fstab. NFS + autofs will mount them as /data1 and /data2 on all the clients
> including the NFS servers. Does this work for you ?
>
> On Sun, Jul 2, 2017 at 1:58 PM, Petros Triantafyllidis via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Hi all,
>>   I am very new to IPA and still a bit before going into production, so
>> apologies in advance.
>>
>> The plan is to have a number of servers that each one shares a space via
>> kerberized nfs4 to the others, which makes all of them NFS clients and
>> servers at the same time. On my attempt to setup automount globally via IdM
>> and sssd, I realized that when a machine is configured as nfs server, it
>> needs autofs.service to be stopped in order to access it's local shares
>> mounted via fstab. If I use /etc/auto.master to mount the local shares
>> instead of fstab, then autofs.service may (actually must) run and
>> everything works properly but, doing so, I don't have the advantage of one
>> central configuration location any more.
>> The preferred scenario for each server would be to mount its local shares
>> via fstab and the remote shares via sssd automount. Am I missing something?
>>
>> Thanks in advance,
>> Petros
>>
>>
> --
> Dr. TRIANTAFYLLIDIS PETROS  E-MAIL: tr...@auth.gr
> ^^  http://users.auth.gr/trian
> Aristotle University - Department of Geophysics, POBox 111,
> 54124 Thessaloniki-GREECE - TEL:+30-2310998585 <+30%20231%20099%208585>, 
> FAX:2310991403
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

Bumping this for help. I need to renew my replica's SSL certificate which
will expire in a month, but I can't find any instructions. It looks like
the replica's web-ui cert isn't tracked by the master or the replica. I'm
using a pretty stock installation with no external CAs or certs. So
ideally, all of this should have been handled automatically by ipa, but it
isn't. There have also been quite a few cert related posts of late which
makes me think if there are (were) some other issues with replica setup a
couple of years ago, which is when the certs were originally generated.

On Mon, May 1, 2017 at 5:39 AM, Prasun Gera  wrote:

> Any ideas why the replica's certs are not being tracked ? That looks like
> an issue in itself. If they are not being tracked, the replica will fail
> once they expire. Is there any way to fix the replica ?
>
> On Sun, Apr 23, 2017 at 10:08 PM, Prasun Gera 
> wrote:
>
>> I tried that, but the replica's "getcert list" doesn't seem to show any
>> results. "Number of certificates and requests being tracked: 0." Is that
>> expected ?
>>
>> On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale 
>> wrote:
>>
>>> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote:
>>> > Thank you. That worked for the master. How do I fix the replica's cert
>>> ?
>>> > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not using
>>> > ipa's DNS at all. Did this happen because of that ?
>>> >
>>> This is not related to DNS.
>>>
>>> To fix the replica, log onto the host and perform the same steps
>>> with Certmonger there.  The tracking Request ID will be different
>>> but otherwise the process is the same.
>>>
>>> Cheers,
>>> Fraser
>>>
>>> > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale 
>>> > wrote:
>>> >
>>> > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
>>> > > > I can confirm that I see this behaviour too. My ipa server install
>>> is a
>>> > > > pretty stock install with no 3rd party certificates.
>>> > > >
>>> > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
>>> > > > simon.willi...@thehelpfulcat.com> wrote:
>>> > > >
>>> > > > > Yesterday, Chrome on both my Ubuntu and Windows machines updated
>>> to
>>> > > > > version 58.0.3029.81.  It appears that this version of Chrome
>>> will not
>>> > > > > trust certificates based on Common Name.  Looking at the Chrome
>>> > > > > documentation and borne out by one of the messages, from Chrome
>>> 58,
>>> > > > > the subjectAltName is required to identify the DNS name of the
>>> host
>>> > > that
>>> > > > > the certificate is issued for.  I would be grateful if someone
>>> could
>>> > > point
>>> > > > > me in the direction of how to recreate my SSL certificates so
>>> that
>>> > > > > the subjectAltName is populated.
>>> > > > >
>>> > > > > Thanks in advance
>>> > > > >
>>> > > > > --
>>> > > > > Manage your subscription for the Freeipa-users mailing list:
>>> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users
>>> > > > > Go to http://freeipa.org for more info on the project
>>> > > > >
>>> > > Which version of IPA are you using?
>>> > >
>>> > > The first thing you should do, which I think should be sufficient in
>>> > > most cases, is to tell certmonger to submit a new cert request for
>>> > > each affected certificate, instructing to include the relevant
>>> > > DNSName in the subjectAltName extension in the CSR.
>>> > >
>>> > > To list certmonger tracking requests and look for the HTTPS
>>> > > certificate.  For example:
>>> > >
>>> > > $ getcert list
>>> > > Number of certificate and requests being tracked: 11
>>> > > ...
>>> > > Request ID '20170418012901':
>>> > > status: MONITORING
>>> > > stuck: no
>>> > > key pair storage: type=NSSDB,location='/etc/
>>> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate
>>> > > DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>> > > certificate: type=NSSDB,location='/etc/
>>> > > httpd/alias',nickname='Server-Cert',token='NSS Certificate DB'
>>> > > CA: IPA
>>> > > issuer: CN=Certificate Authority,O=IPA.LOCAL 201703211317
>>> > > subject: CN=f25-2.ipa.local,O=IPA.LOCAL 201703211317
>>> > > expires: 2019-03-22 03:20:19 UTC
>>> > > dns: f25-2.ipa.local
>>> > > key usage: digitalSignature,nonRepudiatio
>>> n,keyEncipherment,
>>> > > dataEncipherment
>>> > > eku: id-kp-serverAuth,id-kp-clientAuth
>>> > > pre-save command:
>>> > > post-save command: /usr/libexec/ipa/certmonger/re
>>> start_httpd
>>> > > track: yes
>>> > > auto-renew: yes
>>> > > ...
>>> > >
>>> > > Using the Request ID of the HTTPS certificate, resubmit the request
>>> > > but use the ``-D `` option to specify a DNSName to include
>>> > > in the SAN extension:
>>> > >
>>> > >   $ getcert resubmit -i  -D 
>>> > >
>>> > > ``-D `` can be specified multiple times, if necessary.
>>> > >
>>> > > This s

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

Hi Fraser,
I ran that command on the replica (which is where it needs to be run, right
? ), and it finished without any error. However, when I called ipa-getcert
list, it shows an error:

Request ID '20170717180008':
status: MONITORING
* ca-error: Unable to determine principal name for signing request.*
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=ORG
subject: CN=replica.com,O=ORG
expires: 2017-08-27 22:55:11 UTC
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes

On Mon, Jul 17, 2017 at 9:36 AM, Fraser Tweedale 
wrote:

> On Mon, Jul 17, 2017 at 08:41:26AM -0400, Prasun Gera wrote:
> > Bumping this for help. I need to renew my replica's SSL certificate which
> > will expire in a month, but I can't find any instructions. It looks like
> > the replica's web-ui cert isn't tracked by the master or the replica. I'm
> > using a pretty stock installation with no external CAs or certs. So
> > ideally, all of this should have been handled automatically by ipa, but
> it
> > isn't. There have also been quite a few cert related posts of late which
> > makes me think if there are (were) some other issues with replica setup a
> > couple of years ago, which is when the certs were originally generated.
> >
> Hi Prasun,
>
> You can add a tracking request to Certmonger for the cert:
>
> % ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert \
>   -p /etc/httpd/alias/pwdfile.txt  \
>   -K ldap/@ -D 
>
> The `-D ` option will ensure that the CSR contains the
> subject alt name for , which will in turn be propagated to
> the issued certificiate.
>
> Once the tracking request is set up you can renew the cert via
> `ipa-getcert resubmit -i `.
>
> Cheers,
> Fraser
>
> > On Sun, Apr 23, 2017 at 10:08 PM, Prasun Gera 
> wrote:
> >
> > > I tried that, but the replica's "getcert list" doesn't seem to show any
> > > results. "Number of certificates and requests being tracked: 0." Is
> that
> > > expected ?
> > >
> > > On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale 
> > > wrote:
> > >
> > >> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote:
> > >> > Thank you. That worked for the master. How do I fix the replica's
> cert ?
> > >> > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am not
> using
> > >> > ipa's DNS at all. Did this happen because of that ?
> > >> >
> > >> This is not related to DNS.
> > >>
> > >> To fix the replica, log onto the host and perform the same steps
> > >> with Certmonger there.  The tracking Request ID will be different
> > >> but otherwise the process is the same.
> > >>
> > >> Cheers,
> > >> Fraser
> > >>
> > >> > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <
> ftwee...@redhat.com>
> > >> > wrote:
> > >> >
> > >> > > On Thu, Apr 20, 2017 at 07:31:16PM -0400, Prasun Gera wrote:
> > >> > > > I can confirm that I see this behaviour too. My ipa server
> install
> > >> is a
> > >> > > > pretty stock install with no 3rd party certificates.
> > >> > > >
> > >> > > > On Thu, Apr 20, 2017 at 5:46 PM, Simon Williams <
> > >> > > > simon.willi...@thehelpfulcat.com> wrote:
> > >> > > >
> > >> > > > > Yesterday, Chrome on both my Ubuntu and Windows machines
> updated
> > >> to
> > >> > > > > version 58.0.3029.81.  It appears that this version of Chrome
> > >> will not
> > >> > > > > trust certificates based on Common Name.  Looking at the
> Chrome
> > >> > > > > documentation and borne out by one of the messages, from
> Chrome
> > >> 58,
> > >> > > > > the subjectAltName is required to identify the DNS name of the
> > >> host
> > >> > > that
> > >> > > > > the certificate is issued for.  I would be grateful if someone
> > >> could
> > >> > > point
> > >> > > > > me in the direction of how to recreate my SSL certificates so
> that
> > >> > > > > the subjectAltName is populated.
> > >> > > > >
> > >> > > > > Thanks in advance
> > >> > > > >
> > >> > > > > --
> > >> > > > > Manage your subscription for the Freeipa-users mailing list:
> > >> > > > > https://www.redhat.com/mailman/listinfo/freeipa-users
> > >> > > > > Go to http://freeipa.org for more info on the project
> > >> > > > >
> > >> > > Which version of IPA are you using?
> > >> > >
> > >> > > The first thing you should do, which I think should be sufficient
> in
> > >> > > most cases, is to tell certmonger to submit a new cert request for
> > >> > > each affected certificate, instructing to include the relevant
> > >> > > DNSName in the subjectAltName extension in the CSR.
> > >> > >
> > >> > > To list certmonger tracking requests and look for the HTTPS
> > >> > > certificate.  For example:
> > >> > >
> > >> > > $ getcert list
> > >> >

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

Thank you, Fraser. That works. I also added the post-script command
"/usr/libexec/ipa/certmonger/restart_httpd". Upon comparing with the
master, there are quite a few certs that are tracked on the master, and
none on the replica. Do I need to do this same exercise for every cert on
the replica ? These are the nicknames of the certs that are tracked on the
master:

   - location='/etc/httpd/alias',nickname='Signing-Cert'
   - location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
   cert-pki-ca'
   - location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
   cert-pki-ca'
   - location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
   cert-pki-ca'
   - location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
   cert-pki-ca'
   - location='/etc/httpd/alias',nickname='ipaCert'
   - location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert cert-pki-ca'
   - location='/etc/dirsrv/slapd-ORG',nickname='Server-Cert'
   - location='/etc/httpd/alias',nickname='Server-Cert'


On Mon, Jul 17, 2017 at 8:58 PM, Fraser Tweedale 
wrote:

> On Mon, Jul 17, 2017 at 02:06:36PM -0400, Prasun Gera wrote:
> > Hi Fraser,
> > I ran that command on the replica (which is where it needs to be run,
> right
> > ? ), and it finished without any error. However, when I called
> ipa-getcert
> > list, it shows an error:
> >
> > Request ID '20170717180008':
> > status: MONITORING
> > * ca-error: Unable to determine principal name for signing request.*
> > stuck: no
> > key pair storage:
> > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > certificate:
> > type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
> > Certificate DB'
> > CA: IPA
> > issuer: CN=Certificate Authority,O=ORG
> > subject: CN=replica.com,O=ORG
> > expires: 2017-08-27 22:55:11 UTC
> > key usage: digitalSignature,nonRepudiation,keyEncipherment,
> dataEncipherment
> > eku: id-kp-serverAuth,id-kp-clientAuth
> > pre-save command:
> > post-save command:
> > track: yes
> > auto-renew: yes
> >
> Hi Prasun,
>
> I looks like, for some reason the princpial name (-K) and dns name
> (-D) did not make it into the tracking request.  Perhaps I gave you
> an incorrect usage of `getcert start-tracking' (or possibly a bug).
> Anyhow, try:
>
>   getcert resubmit -i  -K  -D 
>
> Hopefully that will cause the principal name to get set properly.
>
> Cheers,
> Fraser
>
> > On Mon, Jul 17, 2017 at 9:36 AM, Fraser Tweedale 
> > wrote:
> >
> > > On Mon, Jul 17, 2017 at 08:41:26AM -0400, Prasun Gera wrote:
> > > > Bumping this for help. I need to renew my replica's SSL certificate
> which
> > > > will expire in a month, but I can't find any instructions. It looks
> like
> > > > the replica's web-ui cert isn't tracked by the master or the
> replica. I'm
> > > > using a pretty stock installation with no external CAs or certs. So
> > > > ideally, all of this should have been handled automatically by ipa,
> but
> > > it
> > > > isn't. There have also been quite a few cert related posts of late
> which
> > > > makes me think if there are (were) some other issues with replica
> setup a
> > > > couple of years ago, which is when the certs were originally
> generated.
> > > >
> > > Hi Prasun,
> > >
> > > You can add a tracking request to Certmonger for the cert:
> > >
> > > % ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert \
> > >   -p /etc/httpd/alias/pwdfile.txt  \
> > >   -K ldap/@ -D 
> > >
> > > The `-D ` option will ensure that the CSR contains the
> > > subject alt name for , which will in turn be propagated to
> > > the issued certificiate.
> > >
> > > Once the tracking request is set up you can renew the cert via
> > > `ipa-getcert resubmit -i `.
> > >
> > > Cheers,
> > > Fraser
> > >
> > > > On Sun, Apr 23, 2017 at 10:08 PM, Prasun Gera  >
> > > wrote:
> > > >
> > > > > I tried that, but the replica's "getcert list" doesn't seem to
> show any
> > > > > results. "Number of certificates and requests being tracked: 0." Is
> > > that
> > > > > expected ?
> > > > >
> > > > > On Sun, Apr 23, 2017 at 8:50 PM, Fraser Tweedale <
> ftwee...@redhat.com>
> > > > > wrote:
> > > > >
> > > > >> On Sun, Apr 23, 2017 at 03:32:19AM -0400, Prasun Gera wrote:
> > > > >> > Thank you. That worked for the master. How do I fix the
> replica's
> > > cert ?
> > > > >> > This is on ipa-server-4.4.0-14.el7_3.7.x86_64 on RHEL7. I am
> not
> > > using
> > > > >> > ipa's DNS at all. Did this happen because of that ?
> > > > >> >
> > > > >> This is not related to DNS.
> > > > >>
> > > > >> To fix the replica, log onto the host and perform the same steps
> > > > >> with Certmonger there.  The tracking Request ID will be different
> > > > >> but otherwise the process is the same.
> > > > >>
> > > > >> Cheers,
> > > > >> Fraser
> > > > >>
> > > > >> > On Thu, Apr 20, 2017 at 9:06 PM, Fraser Tweedale <
> > > ftwee...@redhat.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > >

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

I tried to replicate every one of those on the replica, but I've hit a
snag. The following CA only exists on the master, but not on the replica:

CA 'dogtag-ipa-ca-renew-agent':
is-default: no
ca-type: EXTERNAL
helper-location: /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit

I didn't notice that there were two different CAs, dogtag-ipa-renew-agent
and dogtag-ipa-ca-renew-agent; the former is there on the replica. I seem
to have accidentally assigned dogtag-ipa-renew-agent to ipaCert on the
replica. It didn't show any errors, and seems to be monitoring. I stopped
creating the monitoring requests once I realized this. How do I fix this ?


On Wed, Jul 19, 2017 at 6:23 AM, Fraser Tweedale 
wrote:

> On Wed, Jul 19, 2017 at 05:31:20AM -0400, Prasun Gera wrote:
> > Thank you, Fraser. That works. I also added the post-script command
> > "/usr/libexec/ipa/certmonger/restart_httpd". Upon comparing with the
> > master, there are quite a few certs that are tracked on the master, and
> > none on the replica. Do I need to do this same exercise for every cert on
> > the replica ? These are the nicknames of the certs that are tracked on
> the
> > master:
> >
> >- location='/etc/httpd/alias',nickname='Signing-Cert'
> >- location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert
> >cert-pki-ca'
> >- location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
> >cert-pki-ca'
> >- location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
> >cert-pki-ca'
> >- location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
> >cert-pki-ca'
> >- location='/etc/httpd/alias',nickname='ipaCert'
> >- location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
> cert-pki-ca'
> >- location='/etc/dirsrv/slapd-ORG',nickname='Server-Cert'
> >- location='/etc/httpd/alias',nickname='Server-Cert'
> >
> Strongly advised to track these with equivalent parameters to what
> you find on the master.
>
> Cheers,
> Fraser
>
> >
> > On Mon, Jul 17, 2017 at 8:58 PM, Fraser Tweedale 
> > wrote:
> >
> > > On Mon, Jul 17, 2017 at 02:06:36PM -0400, Prasun Gera wrote:
> > > > Hi Fraser,
> > > > I ran that command on the replica (which is where it needs to be run,
> > > right
> > > > ? ), and it finished without any error. However, when I called
> > > ipa-getcert
> > > > list, it shows an error:
> > > >
> > > > Request ID '20170717180008':
> > > > status: MONITORING
> > > > * ca-error: Unable to determine principal name for signing request.*
> > > > stuck: no
> > > > key pair storage:
> > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-
> Cert',token='NSS
> > > > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
> > > > certificate:
> > > > type=NSSDB,location='/etc/httpd/alias',nickname='Server-
> Cert',token='NSS
> > > > Certificate DB'
> > > > CA: IPA
> > > > issuer: CN=Certificate Authority,O=ORG
> > > > subject: CN=replica.com,O=ORG
> > > > expires: 2017-08-27 22:55:11 UTC
> > > > key usage: digitalSignature,nonRepudiation,keyEncipherment,
> > > dataEncipherment
> > > > eku: id-kp-serverAuth,id-kp-clientAuth
> > > > pre-save command:
> > > > post-save command:
> > > > track: yes
> > > > auto-renew: yes
> > > >
> > > Hi Prasun,
> > >
> > > I looks like, for some reason the princpial name (-K) and dns name
> > > (-D) did not make it into the tracking request.  Perhaps I gave you
> > > an incorrect usage of `getcert start-tracking' (or possibly a bug).
> > > Anyhow, try:
> > >
> > >   getcert resubmit -i  -K  -D 
> > >
> > > Hopefully that will cause the principal name to get set properly.
> > >
> > > Cheers,
> > > Fraser
> > >
> > > > On Mon, Jul 17, 2017 at 9:36 AM, Fraser Tweedale <
> ftwee...@redhat.com>
> > > > wrote:
> > > >
> > > > > On Mon, Jul 17, 2017 at 08:41:26AM -0400, Prasun Gera wrote:
> > > > > > Bumping this for help. I need to renew my replica's SSL
> certificate
> > > which
> > > > > > will expire in a month, but I can't find any instructions. It
> looks
> > > like
> > > > > > the replica's web-ui cert isn't tracked by the master or the
> > > replica. I'm
> > > > > > using a pretty stock installation with no external CAs or certs.
> So
> > > > > > ideally, all of this should have been handled automatically by
> ipa,
> > > but
> > > > > it
> > > > > > isn't. There have also been quite a few cert related posts of
> late
> > > which
> > > > > > makes me think if there are (were) some other issues with replica
> > > setup a
> > > > > > couple of years ago, which is when the certs were originally
> > > generated.
> > > > > >
> > > > > Hi Prasun,
> > > > >
> > > > > You can add a tracking request to Certmonger for the cert:
> > > > >
> > > > > % ipa-getcert start-tracking -d /etc/httpd/alias -n
> Server-Cert \
> > > > >   -p /etc/httpd/alias/pwdfile.txt  \
> > > > >   -K ldap/@ -D 
> > > > >
> > > > > The `-D ` option will ensure that the CSR contains the
> > > > > subject alt name for , which will in turn be propagated
> to
> > > > > the issue

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

Sorry about this rather long thread, and I appreciate all the help. After
adding the new ca, the new tracking requests show the status as
"CA_WORKING" instead of "MONITORING".

For example, the replica shows this for one of the requests:
Request ID '20170727122353':
status: CA_WORKING
stuck: no
key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-ca-renew-agent
issuer: CN=Certificate Authority,O=ORG.EDU
subject: CN=Certificate Authority,O=ORG.EDU
expires: 2035-04-08 17:34:47 UTC
key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert
cert-pki-ca"
track: yes
auto-renew: yes

Same status for subsystemCert cert-pki-ca. However, ipaCert shows
monitoring, which is also tracked by dogtag-ipa-ca-renew-agent. There are
still a few more left that I need to add. Is this status normal ?


On Mon, Jul 24, 2017 at 6:19 AM, Florence Blanc-Renaud 
wrote:

> On 07/23/2017 01:29 AM, Prasun Gera via FreeIPA-users wrote:
>
>> I tried to replicate every one of those on the replica, but I've hit a
>> snag. The following CA only exists on the master, but not on the replica:
>>
>> CA 'dogtag-ipa-ca-renew-agent':
>> is-default: no
>> ca-type: EXTERNAL
>> helper-location: /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit
>>
>> I didn't notice that there were two different
>> CAs, dogtag-ipa-renew-agent and dogtag-ipa-ca-renew-agent; the former is
>> there on the replica. I seem to have accidentally assigned
>> dogtag-ipa-renew-agent to ipaCert on the replica. It didn't show any
>> errors, and seems to be monitoring. I stopped creating the monitoring
>> requests once I realized this. How do I fix this ?
>>
>> Hi,
>
> you need first to add the CA on the replica with getcert add-ca:
> $ sudo getcert add-ca -c dogtag-ipa-ca-renew-agent -e
> /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit
>
> Then fix the CA used to renew ipaCert:
> - stop tracking with dogtag-ipa-renew-agent
> $ sudo getcert stop-tracking -i 
>
> - start tracking with dogtag-ipa-ca-renew-agent using getcert
> start-tracking + the same options as you did except for the -c
> dogtag-ipa-ca-renew-agent
>
> HTH,
> Flo
>
>
>
>> On Wed, Jul 19, 2017 at 6:23 AM, Fraser Tweedale > <mailto:ftwee...@redhat.com>> wrote:
>>
>> On Wed, Jul 19, 2017 at 05:31:20AM -0400, Prasun Gera wrote:
>> > Thank you, Fraser. That works. I also added the post-script command
>> > "/usr/libexec/ipa/certmonger/restart_httpd". Upon comparing with
>> the
>> > master, there are quite a few certs that are tracked on the master,
>> and
>> > none on the replica. Do I need to do this same exercise for every
>> cert on
>> > the replica ? These are the nicknames of the certs that are tracked
>> on the
>> > master:
>> >
>> >- location='/etc/httpd/alias',nickname='Signing-Cert'
>> >- location='/etc/pki/pki-tomcat/alias',nickname='auditSigningC
>> ert
>> >cert-pki-ca'
>> >- location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert
>> >cert-pki-ca'
>> >- location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert
>> >cert-pki-ca'
>> >- location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
>> >cert-pki-ca'
>> >- location='/etc/httpd/alias',nickname='ipaCert'
>> >- location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
>> cert-pki-ca'
>> >- location='/etc/dirsrv/slapd-ORG',nickname='Server-Cert'
>> >- location='/etc/httpd/alias',nickname='Server-Cert'
>> >
>> Strongly advised to track these with equivalent parameters to what
>> you find on the master.
>>
>> Cheers,
>> Fraser
>>
>> >
>> > On Mon, Jul 17, 2017 at 8:58 PM, Fraser Tweedale <
>> ftwee...@redhat.com <mailto:ftwee...@redhat.com>>
>> > wrote:
>> >
>> > &

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

The entry is present on both master, and replica. Also, the status on
replica for those two has changed to *'ca-error: Invalid cookie: '''*. The
certs listed by certutil on both systems, as well as the ones listed by the
ldap query seem to match. When I try to resubmit, there is also this
message in the system log "dogtag-ipa-ca-renew-agent-submit: Updated
certificate not available". Any way to run some diagnostics on the newly
added dogtag-ipa-ca-renew-agent on the replica ?

On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud 
wrote:

> On 07/27/2017 02:39 PM, Prasun Gera via FreeIPA-users wrote:
>
>> Sorry about this rather long thread, and I appreciate all the help. After
>> adding the new ca, the new tracking requests show the status as
>> "CA_WORKING" instead of "MONITORING".
>>
>> For example, the replica shows this for one of the requests:
>> Request ID '20170727122353':
>> status: CA_WORKING
>> stuck: no
>> key pair storage: type=NSSDB,location='/etc/pki/
>> pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS
>> Certificate DB',pin set
>> certificate: 
>> type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
>> cert-pki-ca',token='NSS Certificate DB'
>> CA: dogtag-ipa-ca-renew-agent
>> issuer: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
>> subject: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
>> expires: 2035-04-08 17:34:47 UTC
>> key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>> pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> "caSigningCert cert-pki-ca"
>> track: yes
>> auto-renew: yes
>>
>> Same status for subsystemCert cert-pki-ca. However, ipaCert shows
>> monitoring, which is also tracked by dogtag-ipa-ca-renew-agent. There are
>> still a few more left that I need to add. Is this status normal ?
>>
>>
>> On Mon, Jul 24, 2017 at 6:19 AM, Florence Blanc-Renaud > <mailto:f...@redhat.com>> wrote:
>>
>> On 07/23/2017 01:29 AM, Prasun Gera via FreeIPA-users wrote:
>>
>> I tried to replicate every one of those on the replica, but I've
>> hit a
>> snag. The following CA only exists on the master, but not on the
>> replica:
>>
>> CA 'dogtag-ipa-ca-renew-agent':
>> is-default: no
>> ca-type: EXTERNAL
>> helper-location:
>> /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit
>>
>> I didn't notice that there were two different
>> CAs, dogtag-ipa-renew-agent and dogtag-ipa-ca-renew-agent; the
>> former is
>> there on the replica. I seem to have accidentally assigned
>> dogtag-ipa-renew-agent to ipaCert on the replica. It didn't show
>> any
>> errors, and seems to be monitoring. I stopped creating the
>> monitoring
>> requests once I realized this. How do I fix this ?
>>
>> Hi,
>>
>> you need first to add the CA on the replica with getcert add-ca:
>> $ sudo getcert add-ca -c dogtag-ipa-ca-renew-agent -e
>> /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit
>>
>> Then fix the CA used to renew ipaCert:
>> - stop tracking with dogtag-ipa-renew-agent
>> $ sudo getcert stop-tracking -i 
>>
>> - start tracking with dogtag-ipa-ca-renew-agent using getcert
>> start-tracking + the same options as you did except for the -c
>> dogtag-ipa-ca-renew-agent
>>
>> HTH,
>> Flo
>>
>>
>>
>> On Wed, Jul 19, 2017 at 6:23 AM, Fraser Tweedale
>> mailto:ftwee...@redhat.com>
>> <mailto:ftwee...@redhat.com <mailto:ftwee...@redhat.com>>> wrote:
>>
>>  On Wed, Jul 19, 2017 at 05:31:20AM -0400, Prasun Gera wrote:
>>  > Thank you, Fraser. That works. I also added the
>> post-script command
>>  > "/usr/libexec/ipa/certmonger/restart_httpd". Upon
>> comparing with the
>>  > master, there are quite a few certs that are tracked on
>> the master, and
>>  > none on the replica. Do I need to do this same exercise
>> for every cert on
>>  > the replica ? These are the nicknames of the certs that
>> are tracked on the
>

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

They are published, or at least it would seem that way. These were my
queries:
ldapsearch -h ipa_master -x -D 'cn=directory manager' -b cn="subsystemCert
cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
ldapsearch -h ipa_replica -x -D 'cn=directory manager' -b cn="subsystemCert
cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
On master: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n "subsystemCert
cert-pki-ca" -a
On replica: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n "subsystemCert
cert-pki-ca" -a

They all return the same cert.

Also, there was another thread on the mailing list with similar symptoms.
I'm not sure if there was a resolution.
https://www.redhat.com/archives/freeipa-users/2017-January/msg00111.html



On Mon, Jul 31, 2017 at 2:40 PM, Rob Crittenden  wrote:

> Prasun Gera via FreeIPA-users wrote:
> > The entry is present on both master, and replica. Also, the status on
> > replica for those two has changed to *'ca-error: Invalid cookie: '''*.
> > The certs listed by certutil on both systems, as well as the ones listed
> > by the ldap query seem to match. When I try to resubmit, there is also
> > this message in the system log "dogtag-ipa-ca-renew-agent-submit:
> > Updated certificate not available". Any way to run some diagnostics on
> > the newly added dogtag-ipa-ca-renew-agent on the replica ?
>
> Did you follow Flo's previous advice and look in LDAP to see if the
> updated certificates were published? It would seem that they were not.
>
> rob
>
> >
> > On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud  > <mailto:f...@redhat.com>> wrote:
> >
> > On 07/27/2017 02:39 PM, Prasun Gera via FreeIPA-users wrote:
> >
> > Sorry about this rather long thread, and I appreciate all the
> > help. After adding the new ca, the new tracking requests show
> > the status as "CA_WORKING" instead of "MONITORING".
> >
> > For example, the replica shows this for one of the requests:
> > Request ID '20170727122353':
> > status: CA_WORKING
> > stuck: no
> > key pair storage:
> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
> caSigningCert
> > cert-pki-ca',token='NSS Certificate DB',pin set
> > certificate:
> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
> caSigningCert
> > cert-pki-ca',token='NSS Certificate DB'
> > CA: dogtag-ipa-ca-renew-agent
> > issuer: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
> > <http://ORG.EDU>
> > subject: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
> > <http://ORG.EDU>
> > expires: 2035-04-08 17:34:47 UTC
> > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
> > "caSigningCert cert-pki-ca"
> > track: yes
> > auto-renew: yes
> >
> >     Same status for subsystemCert cert-pki-ca. However, ipaCert
> > shows monitoring, which is also tracked by
> > dogtag-ipa-ca-renew-agent. There are still a few more left that
> > I need to add. Is this status normal ?
> >
> >
> > On Mon, Jul 24, 2017 at 6:19 AM, Florence Blanc-Renaud
> > mailto:f...@redhat.com> <mailto:f...@redhat.com
> > <mailto:f...@redhat.com>>> wrote:
> >
> > On 07/23/2017 01:29 AM, Prasun Gera via FreeIPA-users wrote:
> >
> > I tried to replicate every one of those on the replica,
> > but I've
> > hit a
> > snag. The following CA only exists on the master, but
> > not on the
> > replica:
> >
> > CA 'dogtag-ipa-ca-renew-agent':
> > is-default: no
> > ca-type: EXTERNAL
> > helper-location:
> > /usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit
> >
> > I didn't notice that there were two different
> > CAs, dogtag-ipa-renew-agent and
> > dogtag-ipa-ca-renew-agent; the
> > former is
> > there on the replica. I seem to have accidentally

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

I think the path that is triggered first is from the following code:

if new_cert == old_cert:
syslog.syslog(syslog.LOG_INFO, "Updated certificate not available")

# No cert available yet, tell certmonger to wait another 8 hours

return (WAIT_WITH_DELAY, 8 * 60 * 60, '')

This causes the status to change to CA_WORKING for a while. Later, the
status changes to the cookie error. The old cert is still valid. So is it
supposed to get a new cert ?

On Mon, Jul 31, 2017 at 2:51 PM, Prasun Gera  wrote:

> They are published, or at least it would seem that way. These were my
> queries:
> ldapsearch -h ipa_master -x -D 'cn=directory manager' -b cn="subsystemCert
> cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
> ldapsearch -h ipa_replica -x -D 'cn=directory manager' -b
> cn="subsystemCert cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
> On master: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n "subsystemCert
> cert-pki-ca" -a
> On replica: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
> "subsystemCert cert-pki-ca" -a
>
> They all return the same cert.
>
> Also, there was another thread on the mailing list with similar symptoms.
> I'm not sure if there was a resolution.
> https://www.redhat.com/archives/freeipa-users/2017-January/msg00111.html
>
>
>
> On Mon, Jul 31, 2017 at 2:40 PM, Rob Crittenden 
> wrote:
>
>> Prasun Gera via FreeIPA-users wrote:
>> > The entry is present on both master, and replica. Also, the status on
>> > replica for those two has changed to *'ca-error: Invalid cookie: '''*.
>> > The certs listed by certutil on both systems, as well as the ones listed
>> > by the ldap query seem to match. When I try to resubmit, there is also
>> > this message in the system log "dogtag-ipa-ca-renew-agent-submit:
>> > Updated certificate not available". Any way to run some diagnostics on
>> > the newly added dogtag-ipa-ca-renew-agent on the replica ?
>>
>> Did you follow Flo's previous advice and look in LDAP to see if the
>> updated certificates were published? It would seem that they were not.
>>
>> rob
>>
>> >
>> > On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud > > <mailto:f...@redhat.com>> wrote:
>> >
>> > On 07/27/2017 02:39 PM, Prasun Gera via FreeIPA-users wrote:
>> >
>> > Sorry about this rather long thread, and I appreciate all the
>> > help. After adding the new ca, the new tracking requests show
>> > the status as "CA_WORKING" instead of "MONITORING".
>> >
>> > For example, the replica shows this for one of the requests:
>> > Request ID '20170727122353':
>> > status: CA_WORKING
>> > stuck: no
>> > key pair storage:
>> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',
>> nickname='caSigningCert
>> > cert-pki-ca',token='NSS Certificate DB',pin set
>> > certificate:
>> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',
>> nickname='caSigningCert
>> > cert-pki-ca',token='NSS Certificate DB'
>> > CA: dogtag-ipa-ca-renew-agent
>> > issuer: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
>> > <http://ORG.EDU>
>> > subject: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
>> > <http://ORG.EDU>
>> > expires: 2035-04-08 17:34:47 UTC
>> > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>> > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>> > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>> > "caSigningCert cert-pki-ca"
>> > track: yes
>> > auto-renew: yes
>> >
>> > Same status for subsystemCert cert-pki-ca. However, ipaCert
>> > shows monitoring, which is also tracked by
>> > dogtag-ipa-ca-renew-agent. There are still a few more left that
>> > I need to add. Is this status normal ?
>> >
>> >
>> > On Mon, Jul 24, 2017 at 6:19 AM, Florence Blanc-Renaud
>> > mailto:f...@redhat.com> <mailto:f...@redhat.com
>> > <mailto:f...@redhat.com>>> wrote:
>> >
>> > On 07/23/2017 01:29 AM, Prasun Gera via FreeIPA-users wrote:
>> &

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

[Prasun Gera via FreeIPA-users]

I think this has resolved itself on its own after the update to RHEL 7.4.
So that was a pleasant surprise.

On Wed, Aug 2, 2017 at 8:53 AM, Prasun Gera  wrote:

> I think the path that is triggered first is from the following code:
>
> if new_cert == old_cert:
>
> syslog.syslog(syslog.LOG_INFO, "Updated certificate not
> available")
> # No cert available yet, tell certmonger to wait another 8 hours
>
> return (WAIT_WITH_DELAY, 8 * 60 * 60, '')
>
> This causes the status to change to CA_WORKING for a while. Later, the
> status changes to the cookie error. The old cert is still valid. So is it
> supposed to get a new cert ?
>
> On Mon, Jul 31, 2017 at 2:51 PM, Prasun Gera 
> wrote:
>
>> They are published, or at least it would seem that way. These were my
>> queries:
>> ldapsearch -h ipa_master -x -D 'cn=directory manager' -b
>> cn="subsystemCert cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
>> ldapsearch -h ipa_replica -x -D 'cn=directory manager' -b
>> cn="subsystemCert cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
>> On master: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
>> "subsystemCert cert-pki-ca" -a
>> On replica: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
>> "subsystemCert cert-pki-ca" -a
>>
>> They all return the same cert.
>>
>> Also, there was another thread on the mailing list with similar symptoms.
>> I'm not sure if there was a resolution.
>> https://www.redhat.com/archives/freeipa-users/2017-January/msg00111.html
>>
>>
>>
>> On Mon, Jul 31, 2017 at 2:40 PM, Rob Crittenden 
>> wrote:
>>
>>> Prasun Gera via FreeIPA-users wrote:
>>> > The entry is present on both master, and replica. Also, the status on
>>> > replica for those two has changed to *'ca-error: Invalid cookie: '''*.
>>> > The certs listed by certutil on both systems, as well as the ones
>>> listed
>>> > by the ldap query seem to match. When I try to resubmit, there is also
>>> > this message in the system log "dogtag-ipa-ca-renew-agent-submit:
>>> > Updated certificate not available". Any way to run some diagnostics on
>>> > the newly added dogtag-ipa-ca-renew-agent on the replica ?
>>>
>>> Did you follow Flo's previous advice and look in LDAP to see if the
>>> updated certificates were published? It would seem that they were not.
>>>
>>> rob
>>>
>>> >
>>> > On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud >> > <mailto:f...@redhat.com>> wrote:
>>> >
>>> > On 07/27/2017 02:39 PM, Prasun Gera via FreeIPA-users wrote:
>>> >
>>> > Sorry about this rather long thread, and I appreciate all the
>>> > help. After adding the new ca, the new tracking requests show
>>> > the status as "CA_WORKING" instead of "MONITORING".
>>> >
>>> > For example, the replica shows this for one of the requests:
>>> > Request ID '20170727122353':
>>> > status: CA_WORKING
>>> > stuck: no
>>> > key pair storage:
>>> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
>>> caSigningCert
>>> > cert-pki-ca',token='NSS Certificate DB',pin set
>>> > certificate:
>>> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
>>> caSigningCert
>>> > cert-pki-ca',token='NSS Certificate DB'
>>> > CA: dogtag-ipa-ca-renew-agent
>>> > issuer: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
>>> > <http://ORG.EDU>
>>> > subject: CN=Certificate Authority,O=ORG.EDU <http://ORG.EDU>
>>> > <http://ORG.EDU>
>>> > expires: 2035-04-08 17:34:47 UTC
>>> > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>>> > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>> > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>>> > "caSigningCert cert-pki-ca"
>>> > track: yes
>>> > auto-renew: yes
>>> >
>>> > Same status for subsystemCert cert-pki-ca. However, ipaCert
>>> > shows mo