[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: 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 list -d /etc/pki/pki-tomcat/alias/ -n 'caSigningCert
> > > cert-pki-ca'
>

[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: digitalSignature,nonRepudiation,keyCertSign,cRLSign
> > > profile: caCACert
> > > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
> &g

[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.
> > >
> > > DOMAIN.COM <http://DOMAIN.COM> <http://DOMAIN.COM> IPA CA not
> > found, assuming 3rd party
> > > DOMAIN.COM <http://DOMAIN.C

[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=/usr/libexec/ipa/certmonger/renew_ca_cert
> > \"caSigningCert cert-pki-ca\", template-profile=caCACe

[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: 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 <prasun.g...@gmail.com> 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 <prasun.g...@gmail.com>
> 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 <rcrit...@redhat.com>
>> 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 <f...@redhat.com
>>> > <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 a

[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 <prasun.g...@gmail.com> 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 <rcrit...@redhat.com>
> 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 <f...@redhat.com
>> > <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
>> > <f...@redhat.com <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]

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 <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>
>> 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 <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 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
>> <ftwee...@redhat.com <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
>>  > master:
>>

[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 <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 <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
>> > 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:
>> >
>> > > 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
>>

[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 

[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" <tr...@auth.gr> 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 - 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 <aboko...@redhat.com>
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