[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 >> > > 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 
>>> > 
>>> > 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
>>> > 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/dogta
>>> g-ipa-ca-renew-agent-submit
>>> >
>>> > I didn't notice that there wer

[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 > > > 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 
>> > 
>> > 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
>> > 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/dogta
>> g-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 replic

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

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

[Rob Crittenden via FreeIPA-users]

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

[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 
>> 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='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

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

[Florence Blanc-Renaud via FreeIPA-users]

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 
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='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
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]

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

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

[Florence Blanc-Renaud via FreeIPA-users]

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='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 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
> > > ? ), 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
mailto: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 h

[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

[Fraser Tweedale via FreeIPA-users]

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 
> > > 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 i

[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

[Fraser Tweedale via FreeIPA-users]

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

[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

[Fraser Tweedale via FreeIPA-users]

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 
> >> > 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
> >> > > aut

[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