[Freeipa-users] Re: certmonger Error 77 Problem with the SSL CA cert

[Florence Blanc-Renaud via FreeIPA-users]

On 10/26/18 6:09 PM, Kees Bakker via FreeIPA-users wrote:



On 26-10-18 18:00, Timo Aaltonen wrote:

On 26.10.2018 18.59, Kees Bakker wrote:

On 26-10-18 14:55, Timo Aaltonen wrote:

On 26.10.2018 09:59, Kees Bakker via FreeIPA-users wrote:

On 25-10-18 20:46, Timo Aaltonen wrote:

On 25.10.2018 21.44, Rob Crittenden wrote:

Kees Bakker wrote:

On 25-10-18 16:11, Rob Crittenden wrote:

Kees Bakker via FreeIPA-users wrote:

On 25-10-18 14:18, Rob Crittenden wrote:

Kees Bakker via FreeIPA-users wrote:

Could it be that this error already existed since we started? Notice
the Request ID of 2016..., and the expires: 2018-10-24.

# getcert list -n ipaCert | sed blabla
Number of certificates and requests being tracked: 8.
Request ID '20161103094546':
     status: CA_UNREACHABLE
     ca-error: Error 77 connecting to 
https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with the SSL CA 
cert (path? access rights?).
     stuck: no
     key pair storage: 
type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
     certificate: 
type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS 
Certificate DB'
     CA: dogtag-ipa-ca-renew-agent
     issuer: CN=Certificate Authority,O=MYDOMAIN
     subject: CN=IPA RA,O=MYDOMAIN
     expires: 2018-10-24 08:45:40 UTC
     key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
     eku: id-kp-serverAuth,id-kp-clientAuth
     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
     track: yes
     auto-renew: yes

In other words, is this the same issue as https://pagure.io/freeipa/issue/7422 ?

The problem is your certs expired yesterday so connections won't work
(the code and message don't come from within certmonger).

certmonger _should_ have renewed them. Try killing ntpd, going back a
few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger and
see what happens.


Easy for you to say. You know what you're doing :-)
For me it's all magic.

Anyway, I'll try it. I'm just scared to set the clock back, because there may
be clients in the network that use this server as a NTP server.

Another thing I want to mention is that the error started showing up two days
ago, on Oct 22, while the expiration is today, Oct 24.


It shouldn't take more than a few minutes to roll back time, restart
services and see what happens. I think your NTP clients will be able to
recover ok if the server is not available for a few minutes.

certmonger logs to syslog so you probably want to look at that to see if
you can find a reason the certs weren't renewed automatically.


No, that didn't help.
And in the syslog there was nothing more than this. (I had to stop the
nameserver because it was spitting out lots of messages.)

Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and PKI 
enrollment...
Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and PKI 
enrollment.
Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and PKI 
enrollment...
Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and PKI 
enrollment.
Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 [131018] Error 
77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profile
Review: Problem with the SSL CA cert (path? access rights?).
Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding request to 
dogtag-ipa-renew-agent
Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent 
returned 3
Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 [131018] Error 
77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: 
Problem with the SSL CA cert (path? access rights?).
Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding request to 
dogtag-ipa-renew-agent
Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: dogtag-ipa-renew-agent 
returned 3
Oct 11 06:00:17 ipasrv certmonger[131018]: 2018-10-11 06:00:17 [131018] Error 
77 connecting to https://ipasrv:8443/ca/agent/ca/profileReview: Problem with 
the SSL CA cert (path? access rights?).


Ok, I think I know what is going on. This is Ubuntu which AFAIK still
lacks nss-pem. That is probably why it can't connect to renew the certs.

I don't know if there is a workaround. Timo, do you know?

Ubuntu 18.04 and up have libnsspem, and certmonger depends on it. I've
never tested cert renewal though.


Does that mean, I'm screwed? What options do I have?
Live with it?
Migrate to, say Centos?
Try to upgrade the server to Ubuntu 18.04 (with uncertainty whether it will 
work)?
Something else?

Stock 18.04 has other issues, there's an updated version on
ppa:freeipa/staging which is backported from 18.10 and should be fine
and hopefully 

[Freeipa-users] Re: certmonger Error 77 Problem with the SSL CA cert

[Timo Aaltonen via FreeIPA-users]

On 26.10.2018 19.09, Kees Bakker wrote:
> 
> 
> On 26-10-18 18:00, Timo Aaltonen wrote:
>> On 26.10.2018 18.59, Kees Bakker wrote:
>>> On 26-10-18 14:55, Timo Aaltonen wrote:
 On 26.10.2018 09:59, Kees Bakker via FreeIPA-users wrote:
> On 25-10-18 20:46, Timo Aaltonen wrote:
>> On 25.10.2018 21.44, Rob Crittenden wrote:
>>> Kees Bakker wrote:
 On 25-10-18 16:11, Rob Crittenden wrote:
> Kees Bakker via FreeIPA-users wrote:
>> On 25-10-18 14:18, Rob Crittenden wrote:
>>> Kees Bakker via FreeIPA-users wrote:
 Could it be that this error already existed since we started? 
 Notice
 the Request ID of 2016..., and the expires: 2018-10-24.

 # getcert list -n ipaCert | sed blabla
 Number of certificates and requests being tracked: 8.
 Request ID '20161103094546':
     status: CA_UNREACHABLE
     ca-error: Error 77 connecting to 
 https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem 
 with the SSL CA cert (path? access rights?).
     stuck: no
     key pair storage: 
 type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
  Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
     certificate: 
 type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
  Certificate DB'
     CA: dogtag-ipa-ca-renew-agent
     issuer: CN=Certificate Authority,O=MYDOMAIN
     subject: CN=IPA RA,O=MYDOMAIN
     expires: 2018-10-24 08:45:40 UTC
     key usage: 
 digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
     eku: id-kp-serverAuth,id-kp-clientAuth
     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
     track: yes
     auto-renew: yes

 In other words, is this the same issue as 
 https://pagure.io/freeipa/issue/7422 ?
>>> The problem is your certs expired yesterday so connections won't 
>>> work
>>> (the code and message don't come from within certmonger).
>>>
>>> certmonger _should_ have renewed them. Try killing ntpd, going back 
>>> a
>>> few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger 
>>> and
>>> see what happens.
>>>
>> Easy for you to say. You know what you're doing :-)
>> For me it's all magic.
>>
>> Anyway, I'll try it. I'm just scared to set the clock back, because 
>> there may
>> be clients in the network that use this server as a NTP server.
>>
>> Another thing I want to mention is that the error started showing up 
>> two days
>> ago, on Oct 22, while the expiration is today, Oct 24.
>>
> It shouldn't take more than a few minutes to roll back time, restart
> services and see what happens. I think your NTP clients will be able 
> to
> recover ok if the server is not available for a few minutes.
>
> certmonger logs to syslog so you probably want to look at that to see 
> if
> you can find a reason the certs weren't renewed automatically.
>
 No, that didn't help.
 And in the syslog there was nothing more than this. (I had to stop the
 nameserver because it was spitting out lots of messages.)

 Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
 Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
 Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and 
 PKI enrollment...
 Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and 
 PKI enrollment.
 Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and 
 PKI enrollment...
 Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and 
 PKI enrollment.
 Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 
 [131018] Error 77 connecting to 
 https://ipasrv.mydomain:8443/ca/agent/ca/profile
 Review: Problem with the SSL CA cert (path? access rights?).
 Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
 request to dogtag-ipa-renew-agent
 Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: 
 dogtag-ipa-renew-agent returned 3
 Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 
 [131018] Error 77 connecting to 
 https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with 
 the SSL CA cert (path? access rights?).
 Oct 11 06:00:17 

[Freeipa-users] Re: certmonger Error 77 Problem with the SSL CA cert

[Kees Bakker via FreeIPA-users]

On 26-10-18 18:00, Timo Aaltonen wrote:
> On 26.10.2018 18.59, Kees Bakker wrote:
>> On 26-10-18 14:55, Timo Aaltonen wrote:
>>> On 26.10.2018 09:59, Kees Bakker via FreeIPA-users wrote:
 On 25-10-18 20:46, Timo Aaltonen wrote:
> On 25.10.2018 21.44, Rob Crittenden wrote:
>> Kees Bakker wrote:
>>> On 25-10-18 16:11, Rob Crittenden wrote:
 Kees Bakker via FreeIPA-users wrote:
> On 25-10-18 14:18, Rob Crittenden wrote:
>> Kees Bakker via FreeIPA-users wrote:
>>> Could it be that this error already existed since we started? Notice
>>> the Request ID of 2016..., and the expires: 2018-10-24.
>>>
>>> # getcert list -n ipaCert | sed blabla
>>> Number of certificates and requests being tracked: 8.
>>> Request ID '20161103094546':
>>>     status: CA_UNREACHABLE
>>>     ca-error: Error 77 connecting to 
>>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem 
>>> with the SSL CA cert (path? access rights?).
>>>     stuck: no
>>>     key pair storage: 
>>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>>>  Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
>>>     certificate: 
>>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>>>  Certificate DB'
>>>     CA: dogtag-ipa-ca-renew-agent
>>>     issuer: CN=Certificate Authority,O=MYDOMAIN
>>>     subject: CN=IPA RA,O=MYDOMAIN
>>>     expires: 2018-10-24 08:45:40 UTC
>>>     key usage: 
>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>>     eku: id-kp-serverAuth,id-kp-clientAuth
>>>     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
>>>     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
>>>     track: yes
>>>     auto-renew: yes
>>>
>>> In other words, is this the same issue as 
>>> https://pagure.io/freeipa/issue/7422 ?
>> The problem is your certs expired yesterday so connections won't work
>> (the code and message don't come from within certmonger).
>>
>> certmonger _should_ have renewed them. Try killing ntpd, going back a
>> few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger 
>> and
>> see what happens.
>>
> Easy for you to say. You know what you're doing :-)
> For me it's all magic.
>
> Anyway, I'll try it. I'm just scared to set the clock back, because 
> there may
> be clients in the network that use this server as a NTP server.
>
> Another thing I want to mention is that the error started showing up 
> two days
> ago, on Oct 22, while the expiration is today, Oct 24.
>
 It shouldn't take more than a few minutes to roll back time, restart
 services and see what happens. I think your NTP clients will be able to
 recover ok if the server is not available for a few minutes.

 certmonger logs to syslog so you probably want to look at that to see 
 if
 you can find a reason the certs weren't renewed automatically.

>>> No, that didn't help.
>>> And in the syslog there was nothing more than this. (I had to stop the
>>> nameserver because it was spitting out lots of messages.)
>>>
>>> Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
>>> Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
>>> Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and 
>>> PKI enrollment...
>>> Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and 
>>> PKI enrollment.
>>> Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and 
>>> PKI enrollment...
>>> Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and 
>>> PKI enrollment.
>>> Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 [131018] 
>>> Error 77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profile
>>> Review: Problem with the SSL CA cert (path? access rights?).
>>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
>>> request to dogtag-ipa-renew-agent
>>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>>> dogtag-ipa-renew-agent returned 3
>>> Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 [131018] 
>>> Error 77 connecting to 
>>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with 
>>> the SSL CA cert (path? access rights?).
>>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
>>> request to dogtag-ipa-renew-agent
>>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>>> dogtag-ipa-renew-agent returned 3

[Freeipa-users] Re: certmonger Error 77 Problem with the SSL CA cert

[Kees Bakker via FreeIPA-users]

On 26-10-18 14:55, Timo Aaltonen wrote:
> On 26.10.2018 09:59, Kees Bakker via FreeIPA-users wrote:
>> On 25-10-18 20:46, Timo Aaltonen wrote:
>>> On 25.10.2018 21.44, Rob Crittenden wrote:
 Kees Bakker wrote:
> On 25-10-18 16:11, Rob Crittenden wrote:
>> Kees Bakker via FreeIPA-users wrote:
>>> On 25-10-18 14:18, Rob Crittenden wrote:
 Kees Bakker via FreeIPA-users wrote:
> Could it be that this error already existed since we started? Notice
> the Request ID of 2016..., and the expires: 2018-10-24.
>
> # getcert list -n ipaCert | sed blabla
> Number of certificates and requests being tracked: 8.
> Request ID '20161103094546':
>     status: CA_UNREACHABLE
>     ca-error: Error 77 connecting to 
> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with 
> the SSL CA cert (path? access rights?).
>     stuck: no
>     key pair storage: 
> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>  Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
>     certificate: 
> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>  Certificate DB'
>     CA: dogtag-ipa-ca-renew-agent
>     issuer: CN=Certificate Authority,O=MYDOMAIN
>     subject: CN=IPA RA,O=MYDOMAIN
>     expires: 2018-10-24 08:45:40 UTC
>     key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>     eku: id-kp-serverAuth,id-kp-clientAuth
>     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
>     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
>     track: yes
>     auto-renew: yes
>
> In other words, is this the same issue as 
> https://pagure.io/freeipa/issue/7422 ?
 The problem is your certs expired yesterday so connections won't work
 (the code and message don't come from within certmonger).

 certmonger _should_ have renewed them. Try killing ntpd, going back a
 few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger and
 see what happens.

>>> Easy for you to say. You know what you're doing :-)
>>> For me it's all magic.
>>>
>>> Anyway, I'll try it. I'm just scared to set the clock back, because 
>>> there may
>>> be clients in the network that use this server as a NTP server.
>>>
>>> Another thing I want to mention is that the error started showing up 
>>> two days
>>> ago, on Oct 22, while the expiration is today, Oct 24.
>>>
>> It shouldn't take more than a few minutes to roll back time, restart
>> services and see what happens. I think your NTP clients will be able to
>> recover ok if the server is not available for a few minutes.
>>
>> certmonger logs to syslog so you probably want to look at that to see if
>> you can find a reason the certs weren't renewed automatically.
>>
> No, that didn't help.
> And in the syslog there was nothing more than this. (I had to stop the
> nameserver because it was spitting out lots of messages.)
>
> Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
> Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
> Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and 
> PKI enrollment...
> Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and PKI 
> enrollment.
> Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and 
> PKI enrollment...
> Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and PKI 
> enrollment.
> Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 [131018] 
> Error 77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profile
> Review: Problem with the SSL CA cert (path? access rights?).
> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
> request to dogtag-ipa-renew-agent
> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: 
> dogtag-ipa-renew-agent returned 3
> Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 [131018] 
> Error 77 connecting to 
> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with the 
> SSL CA cert (path? access rights?).
> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
> request to dogtag-ipa-renew-agent
> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: 
> dogtag-ipa-renew-agent returned 3
> Oct 11 06:00:17 ipasrv certmonger[131018]: 2018-10-11 06:00:17 [131018] 
> Error 77 connecting to https://ipasrv:8443/ca/agent/ca/profileReview: 
> Problem with the SSL CA cert (path? access rights?).
>
 Ok, I think I know what is going on. This is Ubuntu which AFAIK still

[Freeipa-users] Re: ipa-replica-manage --force replica.server fails

[Rob Crittenden via FreeIPA-users]

Ralph Crongeyer wrote:
> Well I got it fixed by using ApacheDirectoryStudio and searching for the
> old stuck replica and deleted all of it's entries, which fixed the issues,
> I wish I would have gotten this email sooner, I would have tried what
> you suggested.
> 
> Thanks for your help with this.

Sure, sorry it took so long.

You may want to run: ipa-replica-manage del replica.server --force --cleanup

Just to ensure you got everything.

rob

> 
> Ralph
> 
> On Wed, Oct 24, 2018 at 5:43 PM Rob Crittenden  > wrote:
> 
> Ralph Crongeyer via FreeIPA-users wrote:
> > So it does allow me to login, however there is a popup that says:
> > "Some operations failed.", and a link "View details", when I click on
> > that it shows:
> > "invalid 'PKINIT enabled server': all masters must have IPA master
> role"  
> > And there is a button that says "OK", when I click on that it
> shows this:
> 
> Ok. Start by running:
> 
> $ kinit admin
> $ ipa domainlevel-get
> 
> If it is 1 you can try
> 
> $ ipa server-del --ignore-topology-disconnect --ignore-last-of-role
> --force replica.server
> 
> rob
> 
> >
> >
> >   Runtime error
> >
> > Web UI got in unrecoverable state during "runtime" phase.
> >
> >
> >       Technical details:
> >
> > y.server_config is undefined
> >
> 
> freeipa/ipa/https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:37187
> >
> 
> start_runtime@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:17296
> >
> 
> register_phases/<@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:1253
> >
> 
> _run_phase/<@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3476
> >
> 
> forEach@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:29752
> >
> 
> _run_phase@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3440
> >
> 
> next_phase@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3899
> >
> 
> _run_phase/<@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3626
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> >
> 
> d/t.then@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:62246
> >
> 
> _run_phase@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3548
> >
> 
> next_phase@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3899
> >
> 
> _run_phase/<@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3626
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> >
> 
> d/t.then@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:62246
> >
> 
> _run_phase@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3548
> >
> 
> next_phase@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3899
> >
> 
> _run_phase/<@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3626
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> > l@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60886
> >
> 
> d/this.resolve@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:61873
> >
> 
> dojo/promise/all/https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:85255
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> > l@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60886
> >
> 
> d/this.resolve@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:61873
> >
> 
> register_phases/https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:1092
> >
> 
> on_success@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:34471
> >
> 
> freeipa/rpc/https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:57200
> >
> 
> freeipa/rpc/https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:56993
> >
> 
> freeipa/rpc/https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:56830
> >
> 
> freeipa/rpc/https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:56380
> >
> 
> freeipa/rpc/https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:53826
> > f@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:49586
> >
> 
> dojo/on/https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:45192
> >
> 
> dojo/on/https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:45808
> >
> emit@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:48712
> > c@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:52469
> >
> l@https://ipaca-01.example.com/ipa/ui/js/libs/jquery.js?v=40504:4:24877
> >
> 
> fireWith@https://ipaca-01.example.com/ipa/ui/js/libs/jquery.js?v=40504:4:25702
> 

[Freeipa-users] Re: ipa-replica-manage --force replica.server fails

[Ralph Crongeyer via FreeIPA-users]

Well I got it fixed by using ApacheDirectoryStudio and searching for the
old stuck replica and deleted all of it's entries, which fixed the issues,
I wish I would have gotten this email sooner, I would have tried what you
suggested.

Thanks for your help with this.

Ralph

On Wed, Oct 24, 2018 at 5:43 PM Rob Crittenden  wrote:

> Ralph Crongeyer via FreeIPA-users wrote:
> > So it does allow me to login, however there is a popup that says:
> > "Some operations failed.", and a link "View details", when I click on
> > that it shows:
> > "invalid 'PKINIT enabled server': all masters must have IPA master
> role"
> > And there is a button that says "OK", when I click on that it shows this:
>
> Ok. Start by running:
>
> $ kinit admin
> $ ipa domainlevel-get
>
> If it is 1 you can try
>
> $ ipa server-del --ignore-topology-disconnect --ignore-last-of-role
> --force replica.server
>
> rob
>
> >
> >
> >   Runtime error
> >
> > Web UI got in unrecoverable state during "runtime" phase.
> >
> >
> >   Technical details:
> >
> > y.server_config is undefined
> > freeipa/ipa/ https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:37187
> > start_runtime@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:17296
> > register_phases/<@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:1253
> > _run_phase/<@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3476
> > forEach@
> https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:29752
> > _run_phase@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3440
> > next_phase@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3899
> > _run_phase/<@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3626
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> > d/t.then@
> https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:62246
> > _run_phase@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3548
> > next_phase@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3899
> > _run_phase/<@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3626
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> > d/t.then@
> https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:62246
> > _run_phase@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3548
> > next_phase@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3899
> > _run_phase/<@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:3626
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> > l@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60886
> > d/this.resolve@
> https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:61873
> > dojo/promise/all/ https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:85255
> > c@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60960
> > l@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:60886
> > d/this.resolve@
> https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:61873
> > register_phases/ https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:1092
> > on_success@
> https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:34471
> > freeipa/rpc/ https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:57200
> > freeipa/rpc/ https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:56993
> > freeipa/rpc/ https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:56830
> > freeipa/rpc/ https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:56380
> > freeipa/rpc/ https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:53826
> > f@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:49586
> > dojo/on/ https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:45192
> > dojo/on/ https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:45808
> > emit@https://ipaca-01.example.com/ipa/ui/js/dojo/dojo.js?v=40504:1:48712
> > c@https://ipaca-01.example.com/ipa/ui/js/freeipa/app.js?40504:1:52469
> > l@https://ipaca-01.example.com/ipa/ui/js/libs/jquery.js?v=40504:4:24877
> > fireWith@
> https://ipaca-01.example.com/ipa/ui/js/libs/jquery.js?v=40504:4:25702
> > k@https://ipaca-01.example.com/ipa/ui/js/libs/jquery.js?v=40504:6:5346
> > t/<@https://ipaca-01.example.com/ipa/ui/js/libs/jquery.js?v=40504:6:9152
> >
> > On Tue, Oct 23, 2018 at 4:07 PM Rob Crittenden  > > wrote:
> >
> > Ralph Crongeyer via FreeIPA-users wrote:
> > > Can this be manually removed? W currently can't login to the web
> > portal
> > > due to this issue.
> >
> > I don't understand how one master is affecting the web server of
> > another. By design they are independent. Can you provide details on
> how
> > login is failing?
> >
> > rob
> >
> > >
> > > On Fri, Oct 19, 2018 at 8:42 AM Ralph Crongeyer
> >

[Freeipa-users] Re: certmonger Error 77 Problem with the SSL CA cert

[Kees Bakker via FreeIPA-users]

On 26-10-18 17:33, Timo Aaltonen wrote:
> On 26.10.2018 18.30, Kees Bakker wrote:
>> On 26-10-18 14:55, Timo Aaltonen wrote:
>>> On 26.10.2018 09:59, Kees Bakker via FreeIPA-users wrote:
 On 25-10-18 20:46, Timo Aaltonen wrote:
> On 25.10.2018 21.44, Rob Crittenden wrote:
>> Kees Bakker wrote:
>>> On 25-10-18 16:11, Rob Crittenden wrote:
 Kees Bakker via FreeIPA-users wrote:
> On 25-10-18 14:18, Rob Crittenden wrote:
>> Kees Bakker via FreeIPA-users wrote:
>>> Could it be that this error already existed since we started? Notice
>>> the Request ID of 2016..., and the expires: 2018-10-24.
>>>
>>> # getcert list -n ipaCert | sed blabla
>>> Number of certificates and requests being tracked: 8.
>>> Request ID '20161103094546':
>>>     status: CA_UNREACHABLE
>>>     ca-error: Error 77 connecting to 
>>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem 
>>> with the SSL CA cert (path? access rights?).
>>>     stuck: no
>>>     key pair storage: 
>>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>>>  Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
>>>     certificate: 
>>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>>>  Certificate DB'
>>>     CA: dogtag-ipa-ca-renew-agent
>>>     issuer: CN=Certificate Authority,O=MYDOMAIN
>>>     subject: CN=IPA RA,O=MYDOMAIN
>>>     expires: 2018-10-24 08:45:40 UTC
>>>     key usage: 
>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>>     eku: id-kp-serverAuth,id-kp-clientAuth
>>>     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
>>>     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
>>>     track: yes
>>>     auto-renew: yes
>>>
>>> In other words, is this the same issue as 
>>> https://pagure.io/freeipa/issue/7422 ?
>> The problem is your certs expired yesterday so connections won't work
>> (the code and message don't come from within certmonger).
>>
>> certmonger _should_ have renewed them. Try killing ntpd, going back a
>> few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger 
>> and
>> see what happens.
>>
> Easy for you to say. You know what you're doing :-)
> For me it's all magic.
>
> Anyway, I'll try it. I'm just scared to set the clock back, because 
> there may
> be clients in the network that use this server as a NTP server.
>
> Another thing I want to mention is that the error started showing up 
> two days
> ago, on Oct 22, while the expiration is today, Oct 24.
>
 It shouldn't take more than a few minutes to roll back time, restart
 services and see what happens. I think your NTP clients will be able to
 recover ok if the server is not available for a few minutes.

 certmonger logs to syslog so you probably want to look at that to see 
 if
 you can find a reason the certs weren't renewed automatically.

>>> No, that didn't help.
>>> And in the syslog there was nothing more than this. (I had to stop the
>>> nameserver because it was spitting out lots of messages.)
>>>
>>> Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
>>> Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
>>> Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and 
>>> PKI enrollment...
>>> Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and 
>>> PKI enrollment.
>>> Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and 
>>> PKI enrollment...
>>> Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and 
>>> PKI enrollment.
>>> Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 [131018] 
>>> Error 77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profile
>>> Review: Problem with the SSL CA cert (path? access rights?).
>>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
>>> request to dogtag-ipa-renew-agent
>>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>>> dogtag-ipa-renew-agent returned 3
>>> Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 [131018] 
>>> Error 77 connecting to 
>>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with 
>>> the SSL CA cert (path? access rights?).
>>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
>>> request to dogtag-ipa-renew-agent
>>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>>> dogtag-ipa-renew-agent returned 3

[Freeipa-users] Re: certmonger Error 77 Problem with the SSL CA cert

[Timo Aaltonen via FreeIPA-users]

On 26.10.2018 18.30, Kees Bakker wrote:
> On 26-10-18 14:55, Timo Aaltonen wrote:
>> On 26.10.2018 09:59, Kees Bakker via FreeIPA-users wrote:
>>> On 25-10-18 20:46, Timo Aaltonen wrote:
 On 25.10.2018 21.44, Rob Crittenden wrote:
> Kees Bakker wrote:
>> On 25-10-18 16:11, Rob Crittenden wrote:
>>> Kees Bakker via FreeIPA-users wrote:
 On 25-10-18 14:18, Rob Crittenden wrote:
> Kees Bakker via FreeIPA-users wrote:
>> Could it be that this error already existed since we started? Notice
>> the Request ID of 2016..., and the expires: 2018-10-24.
>>
>> # getcert list -n ipaCert | sed blabla
>> Number of certificates and requests being tracked: 8.
>> Request ID '20161103094546':
>>     status: CA_UNREACHABLE
>>     ca-error: Error 77 connecting to 
>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with 
>> the SSL CA cert (path? access rights?).
>>     stuck: no
>>     key pair storage: 
>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>>  Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
>>     certificate: 
>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS
>>  Certificate DB'
>>     CA: dogtag-ipa-ca-renew-agent
>>     issuer: CN=Certificate Authority,O=MYDOMAIN
>>     subject: CN=IPA RA,O=MYDOMAIN
>>     expires: 2018-10-24 08:45:40 UTC
>>     key usage: 
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>     eku: id-kp-serverAuth,id-kp-clientAuth
>>     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
>>     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
>>     track: yes
>>     auto-renew: yes
>>
>> In other words, is this the same issue as 
>> https://pagure.io/freeipa/issue/7422 ?
> The problem is your certs expired yesterday so connections won't work
> (the code and message don't come from within certmonger).
>
> certmonger _should_ have renewed them. Try killing ntpd, going back a
> few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger 
> and
> see what happens.
>
 Easy for you to say. You know what you're doing :-)
 For me it's all magic.

 Anyway, I'll try it. I'm just scared to set the clock back, because 
 there may
 be clients in the network that use this server as a NTP server.

 Another thing I want to mention is that the error started showing up 
 two days
 ago, on Oct 22, while the expiration is today, Oct 24.

>>> It shouldn't take more than a few minutes to roll back time, restart
>>> services and see what happens. I think your NTP clients will be able to
>>> recover ok if the server is not available for a few minutes.
>>>
>>> certmonger logs to syslog so you probably want to look at that to see if
>>> you can find a reason the certs weren't renewed automatically.
>>>
>> No, that didn't help.
>> And in the syslog there was nothing more than this. (I had to stop the
>> nameserver because it was spitting out lots of messages.)
>>
>> Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
>> Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
>> Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and 
>> PKI enrollment...
>> Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and 
>> PKI enrollment.
>> Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and 
>> PKI enrollment...
>> Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and 
>> PKI enrollment.
>> Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 [131018] 
>> Error 77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profile
>> Review: Problem with the SSL CA cert (path? access rights?).
>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
>> request to dogtag-ipa-renew-agent
>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>> dogtag-ipa-renew-agent returned 3
>> Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 [131018] 
>> Error 77 connecting to 
>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with the 
>> SSL CA cert (path? access rights?).
>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
>> request to dogtag-ipa-renew-agent
>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>> dogtag-ipa-renew-agent returned 3
>> Oct 11 06:00:17 ipasrv certmonger[131018]: 2018-10-11 06:00:17 [131018] 
>> Error 77 connecting to 

[Freeipa-users] Re: Testing requested - certificate checking tool

[Rob Crittenden via FreeIPA-users]

Louis Lagendijk via FreeIPA-users wrote:
> On Mon, 2018-10-22 at 12:07 -0400, Rob Crittenden via FreeIPA-users
> wrote:
>> Gah, regarding
>>
>> Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name':
>> 'IPA',
>> 'cert-database': '/etc/httpd/alias', 'cert-postsave-command':
>> '/usr/libexec/ipa/certmonger/restart_httpd'}
>>
>> never mind. The cert is in the verbose output you sent! It is fine
>> and
>> issued by IPA.
>>
>> So this looks like the tracking is simply missing. Can you run:
>>
>> # ipa-getcert list
>>
>> You should have two certs, one for Apache tracking /etc/httpd/alias
>> and
>> one for LDAP tracking /etc/dirsrv/slapd-REALM
>>
>> If you have one for Apache can you provide the output of the list
>> command?
>>
>> If you don't then you can re-create it (this doesn't touch the certs
>> themselves) via:
>>
>> # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -C
>> /usr/libexec/ipa/certmonger/restart_httpd
>>
> Thanks for looking into my output! Much appreciated
> 
> /etc/httpd/alias is being tracked. Here is the output:
> [root@ipa1 checkcerts]# ipa-getcert list
> Number of certificates and requests being tracked: 9.
> Request ID '20181001153507':
>   status: MONITORING
>   stuck: no
>   key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-HOME-
> FAZANT-NET',nickname='Server-Cert',token='NSS Certificate
> DB',pinfile='/etc/dirsrv/slapd-HOME-FAZANT-NET/pwdfile.txt'
>   certificate: type=NSSDB,location='/etc/dirsrv/slapd-HOME-
> FAZANT-NET',nickname='Server-Cert',token='NSS Certificate DB'
>   CA: IPA
>   issuer: CN=Certificate Authority,O=HOME.FAZANT.NET
>   subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET
>   expires: 2020-10-03 21:06:09 UTC
>   principal name: ldap/ipa1.home.fazant@home.fazant.net
>   key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command: 
>   post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv
> HOME-FAZANT-NET
>   track: yes
>   auto-renew: yes
> Request ID '20181003195731':
>   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=HOME.FAZANT.NET
>   subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET
>   expires: 2020-05-21 13:53:40 UTC
>   principal name: HTTP/ipa1.home.fazant@home.fazant.net
>   key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command: 
>   post-save command: 
>   track: yes
>   auto-renew: yes

It is missing the post-save command. To fix it run:

# ipa-getcert -i 20181003195731 -C /usr/libexec/ipa/certmonger/restart_httpd

The consequence of not having the post-save command is that after the
cert is renewed Apache wouldn't be restarted to utilize it potentially
giving you a bit of downtime.

rob
___
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://getfedora.org/code-of-conduct.html
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: certmonger Error 77 Problem with the SSL CA cert

[Timo Aaltonen via FreeIPA-users]

On 26.10.2018 09:59, Kees Bakker via FreeIPA-users wrote:
> On 25-10-18 20:46, Timo Aaltonen wrote:
>> On 25.10.2018 21.44, Rob Crittenden wrote:
>>> Kees Bakker wrote:
 On 25-10-18 16:11, Rob Crittenden wrote:
> Kees Bakker via FreeIPA-users wrote:
>> On 25-10-18 14:18, Rob Crittenden wrote:
>>> Kees Bakker via FreeIPA-users wrote:
 Could it be that this error already existed since we started? Notice
 the Request ID of 2016..., and the expires: 2018-10-24.

 # getcert list -n ipaCert | sed blabla
 Number of certificates and requests being tracked: 8.
 Request ID '20161103094546':
     status: CA_UNREACHABLE
     ca-error: Error 77 connecting to 
 https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with 
 the SSL CA cert (path? access rights?).
     stuck: no
     key pair storage: 
 type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS 
 Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
     certificate: 
 type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS 
 Certificate DB'
     CA: dogtag-ipa-ca-renew-agent
     issuer: CN=Certificate Authority,O=MYDOMAIN
     subject: CN=IPA RA,O=MYDOMAIN
     expires: 2018-10-24 08:45:40 UTC
     key usage: 
 digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
     eku: id-kp-serverAuth,id-kp-clientAuth
     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
     track: yes
     auto-renew: yes

 In other words, is this the same issue as 
 https://pagure.io/freeipa/issue/7422 ?
>>> The problem is your certs expired yesterday so connections won't work
>>> (the code and message don't come from within certmonger).
>>>
>>> certmonger _should_ have renewed them. Try killing ntpd, going back a
>>> few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger and
>>> see what happens.
>>>
>> Easy for you to say. You know what you're doing :-)
>> For me it's all magic.
>>
>> Anyway, I'll try it. I'm just scared to set the clock back, because 
>> there may
>> be clients in the network that use this server as a NTP server.
>>
>> Another thing I want to mention is that the error started showing up two 
>> days
>> ago, on Oct 22, while the expiration is today, Oct 24.
>>
> It shouldn't take more than a few minutes to roll back time, restart
> services and see what happens. I think your NTP clients will be able to
> recover ok if the server is not available for a few minutes.
>
> certmonger logs to syslog so you probably want to look at that to see if
> you can find a reason the certs weren't renewed automatically.
>
 No, that didn't help.
 And in the syslog there was nothing more than this. (I had to stop the
 nameserver because it was spitting out lots of messages.)

 Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
 Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
 Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and PKI 
 enrollment...
 Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and PKI 
 enrollment.
 Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and PKI 
 enrollment...
 Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and PKI 
 enrollment.
 Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 [131018] 
 Error 77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profile
 Review: Problem with the SSL CA cert (path? access rights?).
 Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
 request to dogtag-ipa-renew-agent
 Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: 
 dogtag-ipa-renew-agent returned 3
 Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 [131018] 
 Error 77 connecting to 
 https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with the 
 SSL CA cert (path? access rights?).
 Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding 
 request to dogtag-ipa-renew-agent
 Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: 
 dogtag-ipa-renew-agent returned 3
 Oct 11 06:00:17 ipasrv certmonger[131018]: 2018-10-11 06:00:17 [131018] 
 Error 77 connecting to https://ipasrv:8443/ca/agent/ca/profileReview: 
 Problem with the SSL CA cert (path? access rights?).

>>> Ok, I think I know what is going on. This is Ubuntu which AFAIK still
>>> lacks nss-pem. That is probably why it can't connect to renew the certs.
>>>
>>> I don't know if there is a workaround. Timo, do you 

[Freeipa-users] Re: IPA sub-CAs; cleaning up spurious Dogtag LWCA entries

[Louis Lagendijk via FreeIPA-users]

On Tue, 2018-10-23 at 11:23 +1000, Fraser Tweedale via FreeIPA-users
wrote:
> Hi Rob,
> 
> (Cc freeipa-users@ for visibility)
> 
> On Mon, Oct 22, 2018 at 04:12:05PM -0400, Rob Crittenden wrote:
> > I've gotten some upstream feedback on my cert checking tool and one
> > user
> > came back with a bunch of errors:
> > 
> > Error looking up CA entry in IPA aeca4a88-630d-4f47-9585-
> > 73bad089260b:
> > no matching entry found
> > Error looking up CA entry in IPA d8a6fe60-eebe-4dfd-8352-
> > 47ca38a29028:
> > no matching entry found
> > Error looking up CA entry in IPA 3203c388-7da5-44d3-923b-
> > dd87a3a62ecb:
> > no matching entry found
> > Error looking up CA entry in IPA f875b832-16cb-4b08-bc8c-
> > 1dbef027d101:
> > no matching entry found
> > Error looking up CA entry in IPA 2e18e695-55c3-4675-a7f2-
> > 84e6b2726893:
> > no matching entry found
> > Error looking up CA entry in IPA 327f1d40-cf4f-4a6a-95b1-
> > 3ba88b725e5f:
> > no matching entry found
> > Error looking up CA entry in IPA 21288a66-d4c2-48d2-9901-
> > a464cd926681:
> > no matching entry found
> > 
> > So these UUID come from ou=authorities, ou=ca, o=ipaca and the
> > equivalent doesn't exist in IPA. Is that by default a problem or is
> > it
> > perfectly valid?
> > 
> > How would you recommend debugging this further?
> > 
> > thanks
> > 
> > rob
> 
> It could be an occurrence of https://pagure.io/dogtagpki/issue/2475
> / https://bugzilla.redhat.com/show_bug.cgi?id=1390322 which resulted
> in the creation of a new lightweight CA (LWCA) entry for the
> host/primary CA each time Dogtag started.  The issue was fixed a
> while ago but we didn't do anything to clean up the spurious
> entries.
> 
> To confirm that this is the issue, check if the extra entries have
> the same 'authorityDN' attribute.  If confirmed the resolution is:
> 
> 1. find the IPA CA authority ID (`ipa ca-show ipa`)
> 
> 2. find all the Dogtag LWCA entries with the same subject DN
> 
> 3. keep the one with the authority ID matching IPA (from step 1) and
>delete the others
> 

Yes this seems to be the problem:
https://ipa1.home.fazant.net/ca/rest/authorities gives me:


I don't fee confident enough rigt now to start deleting entries though

BR, Louis
___
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://getfedora.org/code-of-conduct.html
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: Testing requested - certificate checking tool

[Louis Lagendijk via FreeIPA-users]

Hi Rob,
Here are the answer to your questions.

On Mon, 2018-10-22 at 12:01 -0400, Rob Crittenden via FreeIPA-users
wrote:
> Let's tackle these one at a time.
> 
> Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name':
> 'IPA',
> 'cert-database': '/etc/httpd/alias', 'cert-postsave-command':
> '/usr/libexec/ipa/certmonger/restart_httpd'}
> 
> Did you provide your own certificate for the web server (e.g. like
> from
> Let's Encrypt?) What is the value of NSSNickname in
> /etc/httpd/conf.d/nss.conf?
No, the IPA servers are not publicly reachable, all hosts within my
network use ipa certificates only. Only 2 nodes (https and mail) with
public IP-addresses use let's encrypt

/etc/httpd/conf.d/nss.conf has:
#   SSL Certificate Nickname:
#   The nickname of the RSA server certificate you are going to use.
NSSNickname Server-Cert
#   SSL Certificate Nickname:
#   The nickname of the ECC server certificate you are going to use, if
you
#   have an ECC-enabled version of NSS and mod_nss
#NSSECCNickname Server-Cert-ecc

> 
> Let me get back to you on the template subjects not matching. I want
> to
> run this past the dogtag team to see if my test is correct or not. It
> could be a red herring.
> 

> For all of the "Error looking up CA entry in IPA : no matching
> entry found"
> 
> This means that a subCA is defined in dogtag that is not defined in
> IPA.
> This may not be a problem but it is definitely strange. What this
> test
> does is compare the contents of ou=authorities,ou=ca,o=ipaca to those
> in
> cn=cas,cn=ca,dc=example,dc=com. I'll run this one past the CS team
> too.
> 
> In the meantime can you provide some of the contents of those entries
> that are in dogtag?
> 
> $ ldapsearch -x -D 'cn=directory manager' -W -b
> ou=authorities,ou=ca,o=ipaca > /tmp/cas.ldif
Attached the file as requested
> 
> Validation of /var/lib/ipa/ra-agent.pem failed: Command
> '/usr/bin/openssl verify /var/lib/ipa/ra-agent.pem' returned non-zero
> exit status 2
> 
> According to the verify(1) man page 2 ==
> X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT which suggests that the IPA CA
> is
> not in the global cert bundle.
> 
> This should fix it:
> 
> # ipa-certupdate
> 
That indeed fixed the issue, thanks
> Thanks for helping out!
Well thank you guy for the great product and your efforts to improve
it!
> 
> rob
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: 
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# authorities, ca, ipaca
dn: ou=authorities,ou=ca,o=ipaca
objectClass: top
objectClass: organizationalUnit
ou: authorities

# eb5c7fc3-9263-4d07-b879-d639554403b8, authorities, ca, ipaca
dn: cn=eb5c7fc3-9263-4d07-b879-d639554403b8,ou=authorities,ou=ca,o=ipaca
objectClass: authority
objectClass: top
cn: eb5c7fc3-9263-4d07-b879-d639554403b8
authorityID: eb5c7fc3-9263-4d07-b879-d639554403b8
authorityKeyNickname: caSigningCert cert-pki-ca
authorityEnabled: TRUE
authorityDN: CN=Certificate Authority,O=HOME.FAZANT.NET
description: Host authority

# aeca4a88-630d-4f47-9585-73bad089260b, authorities, ca, ipaca
dn: cn=aeca4a88-630d-4f47-9585-73bad089260b,ou=authorities,ou=ca,o=ipaca
objectClass: authority
objectClass: top
cn: aeca4a88-630d-4f47-9585-73bad089260b
authorityID: aeca4a88-630d-4f47-9585-73bad089260b
authorityKeyNickname: caSigningCert cert-pki-ca
authorityEnabled: TRUE
authorityDN: CN=Certificate Authority,O=HOME.FAZANT.NET
description: Host authority

# d8a6fe60-eebe-4dfd-8352-47ca38a29028, authorities, ca, ipaca
dn: cn=d8a6fe60-eebe-4dfd-8352-47ca38a29028,ou=authorities,ou=ca,o=ipaca
objectClass: authority
objectClass: top
cn: d8a6fe60-eebe-4dfd-8352-47ca38a29028
authorityID: d8a6fe60-eebe-4dfd-8352-47ca38a29028
authorityKeyNickname: caSigningCert cert-pki-ca
authorityEnabled: TRUE
authorityDN: CN=Certificate Authority,O=HOME.FAZANT.NET
description: Host authority

# 3203c388-7da5-44d3-923b-dd87a3a62ecb, authorities, ca, ipaca
dn: cn=3203c388-7da5-44d3-923b-dd87a3a62ecb,ou=authorities,ou=ca,o=ipaca
objectClass: authority
objectClass: top
cn: 3203c388-7da5-44d3-923b-dd87a3a62ecb
authorityID: 3203c388-7da5-44d3-923b-dd87a3a62ecb
authorityKeyNickname: caSigningCert cert-pki-ca
authorityEnabled: TRUE
authorityDN: CN=Certificate Authority,O=HOME.FAZANT.NET
description: Host authority

# f875b832-16cb-4b08-bc8c-1dbef027d101, authorities, ca, ipaca
dn: cn=f875b832-16cb-4b08-bc8c-1dbef027d101,ou=authorities,ou=ca,o=ipaca
objectClass: authority
objectClass: top
cn: f875b832-16cb-4b08-bc8c-1dbef027d101
authorityID: f875b832-16cb-4b08-bc8c-1dbef027d101
authorityKeyNickname: caSigningCert 

[Freeipa-users] Re: Testing requested - certificate checking tool

[Louis Lagendijk via FreeIPA-users]

On Mon, 2018-10-22 at 12:07 -0400, Rob Crittenden via FreeIPA-users
wrote:
> Gah, regarding
> 
> Missing tracking for {'cert-nickname': 'Server-Cert', 'ca-name':
> 'IPA',
> 'cert-database': '/etc/httpd/alias', 'cert-postsave-command':
> '/usr/libexec/ipa/certmonger/restart_httpd'}
> 
> never mind. The cert is in the verbose output you sent! It is fine
> and
> issued by IPA.
> 
> So this looks like the tracking is simply missing. Can you run:
> 
> # ipa-getcert list
> 
> You should have two certs, one for Apache tracking /etc/httpd/alias
> and
> one for LDAP tracking /etc/dirsrv/slapd-REALM
> 
> If you have one for Apache can you provide the output of the list
> command?
> 
> If you don't then you can re-create it (this doesn't touch the certs
> themselves) via:
> 
> # ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -C
> /usr/libexec/ipa/certmonger/restart_httpd
> 
Thanks for looking into my output! Much appreciated

/etc/httpd/alias is being tracked. Here is the output:
[root@ipa1 checkcerts]# ipa-getcert list
Number of certificates and requests being tracked: 9.
Request ID '20181001153507':
status: MONITORING
stuck: no
key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-HOME-
FAZANT-NET',nickname='Server-Cert',token='NSS Certificate
DB',pinfile='/etc/dirsrv/slapd-HOME-FAZANT-NET/pwdfile.txt'
certificate: type=NSSDB,location='/etc/dirsrv/slapd-HOME-
FAZANT-NET',nickname='Server-Cert',token='NSS Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=HOME.FAZANT.NET
subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET
expires: 2020-10-03 21:06:09 UTC
principal name: ldap/ipa1.home.fazant@home.fazant.net
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: 
post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv
HOME-FAZANT-NET
track: yes
auto-renew: yes
Request ID '20181003195731':
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=HOME.FAZANT.NET
subject: CN=ipa1.home.fazant.net,O=HOME.FAZANT.NET
expires: 2020-05-21 13:53:40 UTC
principal name: HTTP/ipa1.home.fazant@home.fazant.net
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command: 
post-save command: 
track: yes
auto-renew: yes

BR, Louis
___
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://getfedora.org/code-of-conduct.html
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: ipa.service "fails" to start

[Florence Blanc-Renaud via FreeIPA-users]

On 10/26/18 7:36 AM, Z D via FreeIPA-users wrote:

Hi Rob, I follow one of your suggestions in another post, it's :
"certmonger _should_ have renewed them. Try killing ntpd, going back a few days, 
restart krb5kdc, dirsrv, httpd and the CA then certmonger and see what happens"

I did it, no success with messages:

- MainThread  ipa DEBUG   Could not connect to the Directory Server on 
ca-ldap01.domain.com: Insufficient access:  Invalid credentials
- ca-dap01 certmonger: 2018-08-07 10:40:39 [4831] Internal error
- ca-ldap01 [sssd[ldap_child[5045]]]: Failed to initialize credentials using 
keytab [MEMORY:/etc/krb5.keytab]: Cannot contact any KDC for realm 
'DOMAIN.COM'. Unable to create GSSAPI-encrypted LDAP connection.
- ca-ldap01 [sssd[ldap_child[5045]]]: Cannot contact any KDC for realm 
'DOMAIN.COM'

And I notice that Kerberos somehow still shows current date, instead of 
2018-08-07 (my back in time).

[root@ca-ldap01 ~]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ad...@domain.com
Valid starting   Expires  Service principal
10/25/2018 20:55:02  10/26/2018 20:54:58  krbtgt/domain@domain.com

Is this reason for failure?


Hi,

when you go back in time, avoid using ipactl start to restart all the 
services as it will restart ntpd (and set back the time to the current 
time). Use systemctl start instead.


flo

___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org


___
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://getfedora.org/code-of-conduct.html
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: Is IPA-AD two-way trust really two-way?

[Winfried de Heiden via FreeIPA-users]

Hi all,

Thanks! This explains a lot, I'm happy :)

Winfried

Alexander Bokovoy via FreeIPA-users schreef op 26-10-2018 11:16:

On pe, 26 loka 2018, Winfried de Heiden wrote:

Hi all,

Refering to this bit of older post,

What now the difference between a One-way or Two-Way Trust anyway? 
The docs are not too clear abut it:


" Two-way trust enables AD users and groups to access resources in 
IdM.
However, the two-way trust in IdM does not give the users any 
additional
rights compared to the one-way trust solution in AD. Both solutions 
are

considered equally secure because of default cross-forest trust SID
filtering settings"

What a use-case for using a Two-Way Trust? (since Windows cannot use
IPA as a AD replacement)

Originally we implemented two-way trust first because it was easier to
do than one-way trust from technical perspective. It allowed machines
from IPA domain to directly query AD DCs about needed information using
their own host/... Kerberos principals for authentication purposes.

However, a lot of customers were concerned with with AD trusting IPA
because it wasn't how AD domain controllers resolved identities (and 
ran
authentication proxying) over trust. We implemented one-way trust with 
a

proper setup and actually moved to always use the credentials
one-way-like in two-way trust too with FreeIPA 4.6/latest SSSD
1.15/1.16.

However, there is one missing part for a one-way trust: a one-way trust
with a shared secret. If you are using a shared secret that is provided
to you by AD admins (as opposed to be generated by 'ipa trust-add'
automatically), one-way trust cannot be established. A long story 
short,

both FreeIPA and SSSD lacked required logic to allow Windows to
perform validation of the trust in this case from a Windows UI and we
couldn't initiate the validation from IPA side as we didn't have
administrative credentials to AD DCs.

So right now two-way trust with a shared secret is your solution for
this case, although I'd rather suggest to establish a normal one-way
trust with AD admin credentials to get a stronger trust secret 
generated

for you by 'ipa trust-add'.





Winfried

-Oorspronkelijk bericht-
Van: Alexander Bokovoy via FreeIPA-users 

Antwoord-naar: FreeIPA users list 


Aan: FreeIPA users list 
Cc: Michal Sladek , Alexander Bokovoy 


Onderwerp: [Freeipa-users] Re: Is IPA-AD two-way trust really two-way?
Datum: Thu, 23 Aug 2018 12:08:17 +0300

On to, 23 elo 2018, Michal Sladek via FreeIPA-users wrote:
Hello,
I would like to use IPA server in heterogeneous environment with Linux 
servers and Windows workstations.IPA domain would be used as a primary 
source of users and groups.AD domain would be used for management of 
Widows hosts only (group policies etc.).
I have setup a test network with two-trust between AD and IPA 
domainand realized, that IPA domain sees AD users but AD domain 
doesn't seeIPA users. Am I missing something or the two-way trust is 
not two-wayin fact?It is two-way in principle. However, FreeIPA does 
not implement featuresrequired by AD DC to resolve IPA users on 
Windows workstations. It is onour long term roadmap.
-- / Alexander BokovoySr. Principal Software EngineerSecurity / 
Identity Management EngineeringRed Hat Limited, 
Finland___FreeIPA-users 
mailing list -- freeipa-users@lists.fedorahosted.orgTo unsubscribe 
send an email to freeipa-users-leave@lists.fedorahosted.orgFedora Code 
of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/OJCXN7VI2NZAUWUHVZDKEZB7SF72NSR2/



___
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://getfedora.org/code-of-conduct.html
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: Is IPA-AD two-way trust really two-way?

[Alexander Bokovoy via FreeIPA-users]

On pe, 26 loka 2018, Winfried de Heiden wrote:

Hi all,

Refering to this bit of older post,

What now the difference between a One-way or Two-Way Trust anyway? The docs 
are not too clear abut it:

" Two-way trust enables AD users and groups to access resources in IdM.
However, the two-way trust in IdM does not give the users any additional
rights compared to the one-way trust solution in AD. Both solutions are
considered equally secure because of default cross-forest trust SID
filtering settings"

What a use-case for using a Two-Way Trust? (since Windows cannot use
IPA as a AD replacement)

Originally we implemented two-way trust first because it was easier to
do than one-way trust from technical perspective. It allowed machines
from IPA domain to directly query AD DCs about needed information using
their own host/... Kerberos principals for authentication purposes.

However, a lot of customers were concerned with with AD trusting IPA
because it wasn't how AD domain controllers resolved identities (and ran
authentication proxying) over trust. We implemented one-way trust with a
proper setup and actually moved to always use the credentials
one-way-like in two-way trust too with FreeIPA 4.6/latest SSSD
1.15/1.16.

However, there is one missing part for a one-way trust: a one-way trust
with a shared secret. If you are using a shared secret that is provided
to you by AD admins (as opposed to be generated by 'ipa trust-add'
automatically), one-way trust cannot be established. A long story short,
both FreeIPA and SSSD lacked required logic to allow Windows to
perform validation of the trust in this case from a Windows UI and we
couldn't initiate the validation from IPA side as we didn't have
administrative credentials to AD DCs.

So right now two-way trust with a shared secret is your solution for
this case, although I'd rather suggest to establish a normal one-way
trust with AD admin credentials to get a stronger trust secret generated
for you by 'ipa trust-add'.





Winfried

-Oorspronkelijk bericht-
Van: Alexander Bokovoy via FreeIPA-users 
Antwoord-naar: FreeIPA users list 
Aan: FreeIPA users list 
Cc: Michal Sladek , Alexander Bokovoy 
Onderwerp: [Freeipa-users] Re: Is IPA-AD two-way trust really two-way?
Datum: Thu, 23 Aug 2018 12:08:17 +0300

On to, 23 elo 2018, Michal Sladek via FreeIPA-users wrote:
Hello,
I would like to use IPA server in heterogeneous environment with Linux servers 
and Windows workstations.IPA domain would be used as a primary source of users 
and groups.AD domain would be used for management of Widows hosts only (group 
policies etc.).
I have setup a test network with two-trust between AD and IPA domainand 
realized, that IPA domain sees AD users but AD domain doesn't seeIPA users. Am 
I missing something or the two-way trust is not two-wayin fact?It is two-way in 
principle. However, FreeIPA does not implement featuresrequired by AD DC to 
resolve IPA users on Windows workstations. It is onour long term roadmap.
-- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity 
Management EngineeringRed Hat Limited, 
Finland___FreeIPA-users mailing 
list -- freeipa-users@lists.fedorahosted.orgTo unsubscribe send an email to 
freeipa-users-leave@lists.fedorahosted.orgFedora Code of Conduct: 
https://getfedora.org/code-of-conduct.htmlList Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/OJCXN7VI2NZAUWUHVZDKEZB7SF72NSR2/





--
/ 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://getfedora.org/code-of-conduct.html
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: Is IPA-AD two-way trust really two-way?

[Winfried de Heiden via FreeIPA-users]

Hi all,

Refering to this bit of older post,

What now the difference between a One-way or Two-Way Trust anyway? The docs 
are not too clear abut it:

" Two-way trust enables AD users and groups to access resources in IdM. 
However, the two-way trust in IdM does not give the users any additional
 rights compared to the one-way trust solution in AD. Both solutions are
 considered equally secure because of default cross-forest trust SID 
filtering settings"

What a use-case for using a Two-Way Trust? (since Windows cannot use IPA as a 
AD replacement)

Winfried

-Oorspronkelijk bericht-
Van: Alexander Bokovoy via FreeIPA-users 
Antwoord-naar: FreeIPA users list 
Aan: FreeIPA users list 
Cc: Michal Sladek , Alexander Bokovoy 
Onderwerp: [Freeipa-users] Re: Is IPA-AD two-way trust really two-way?
Datum: Thu, 23 Aug 2018 12:08:17 +0300

On to, 23 elo 2018, Michal Sladek via FreeIPA-users wrote:
Hello,
I would like to use IPA server in heterogeneous environment with Linux servers 
and Windows workstations.IPA domain would be used as a primary source of users 
and groups.AD domain would be used for management of Widows hosts only (group 
policies etc.).
I have setup a test network with two-trust between AD and IPA domainand 
realized, that IPA domain sees AD users but AD domain doesn't seeIPA users. Am 
I missing something or the two-way trust is not two-wayin fact?It is two-way in 
principle. However, FreeIPA does not implement featuresrequired by AD DC to 
resolve IPA users on Windows workstations. It is onour long term roadmap.
-- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity 
Management EngineeringRed Hat Limited, 
Finland___FreeIPA-users mailing 
list -- freeipa-users@lists.fedorahosted.orgTo unsubscribe send an email to 
freeipa-users-leave@lists.fedorahosted.orgFedora Code of Conduct: 
https://getfedora.org/code-of-conduct.htmlList Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: 
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/OJCXN7VI2NZAUWUHVZDKEZB7SF72NSR2/



signature.asc
Description: This is a digitally signed message part
___
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://getfedora.org/code-of-conduct.html
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: certmonger Error 77 Problem with the SSL CA cert

[Kees Bakker via FreeIPA-users]

On 25-10-18 20:46, Timo Aaltonen wrote:
> On 25.10.2018 21.44, Rob Crittenden wrote:
>> Kees Bakker wrote:
>>> On 25-10-18 16:11, Rob Crittenden wrote:
 Kees Bakker via FreeIPA-users wrote:
> On 25-10-18 14:18, Rob Crittenden wrote:
>> Kees Bakker via FreeIPA-users wrote:
>>> Could it be that this error already existed since we started? Notice
>>> the Request ID of 2016..., and the expires: 2018-10-24.
>>>
>>> # getcert list -n ipaCert | sed blabla
>>> Number of certificates and requests being tracked: 8.
>>> Request ID '20161103094546':
>>>     status: CA_UNREACHABLE
>>>     ca-error: Error 77 connecting to 
>>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with 
>>> the SSL CA cert (path? access rights?).
>>>     stuck: no
>>>     key pair storage: 
>>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS 
>>> Certificate DB',pinfile='/etc/apache2/nssdb/pwdfile.txt'
>>>     certificate: 
>>> type=NSSDB,location='/etc/apache2/nssdb',nickname='ipaCert',token='NSS 
>>> Certificate DB'
>>>     CA: dogtag-ipa-ca-renew-agent
>>>     issuer: CN=Certificate Authority,O=MYDOMAIN
>>>     subject: CN=IPA RA,O=MYDOMAIN
>>>     expires: 2018-10-24 08:45:40 UTC
>>>     key usage: 
>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>>     eku: id-kp-serverAuth,id-kp-clientAuth
>>>     pre-save command: /usr/lib/ipa/certmonger/renew_ra_cert_pre
>>>     post-save command: /usr/lib/ipa/certmonger/renew_ra_cert
>>>     track: yes
>>>     auto-renew: yes
>>>
>>> In other words, is this the same issue as 
>>> https://pagure.io/freeipa/issue/7422 ?
>> The problem is your certs expired yesterday so connections won't work
>> (the code and message don't come from within certmonger).
>>
>> certmonger _should_ have renewed them. Try killing ntpd, going back a
>> few days, restart krb5kdc, dirsrv, httpd and the CA then certmonger and
>> see what happens.
>>
> Easy for you to say. You know what you're doing :-)
> For me it's all magic.
>
> Anyway, I'll try it. I'm just scared to set the clock back, because there 
> may
> be clients in the network that use this server as a NTP server.
>
> Another thing I want to mention is that the error started showing up two 
> days
> ago, on Oct 22, while the expiration is today, Oct 24.
>
 It shouldn't take more than a few minutes to roll back time, restart
 services and see what happens. I think your NTP clients will be able to
 recover ok if the server is not available for a few minutes.

 certmonger logs to syslog so you probably want to look at that to see if
 you can find a reason the certs weren't renewed automatically.

>>> No, that didn't help.
>>> And in the syslog there was nothing more than this. (I had to stop the
>>> nameserver because it was spitting out lots of messages.)
>>>
>>> Oct 11 06:00:00 ipasrv systemd[1]: Time has been changed
>>> Oct 11 06:00:00 ipasrv systemd[52167]: Time has been changed
>>> Oct 11 06:00:04 ipasrv systemd[1]: Stopping Certificate monitoring and PKI 
>>> enrollment...
>>> Oct 11 06:00:04 ipasrv systemd[1]: Stopped Certificate monitoring and PKI 
>>> enrollment.
>>> Oct 11 06:00:04 ipasrv systemd[1]: Starting Certificate monitoring and PKI 
>>> enrollment...
>>> Oct 11 06:00:04 ipasrv systemd[1]: Started Certificate monitoring and PKI 
>>> enrollment.
>>> Oct 11 06:00:05 ipasrv certmonger[131018]: 2018-10-11 06:00:05 [131018] 
>>> Error 77 connecting to https://ipasrv.mydomain:8443/ca/agent/ca/profile
>>> Review: Problem with the SSL CA cert (path? access rights?).
>>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding request 
>>> to dogtag-ipa-renew-agent
>>> Oct 11 06:00:07 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>>> dogtag-ipa-renew-agent returned 3
>>> Oct 11 06:00:07 ipasrv certmonger[131018]: 2018-10-11 06:00:07 [131018] 
>>> Error 77 connecting to 
>>> https://ipasrv.mydomain:8443/ca/agent/ca/profileReview: Problem with the 
>>> SSL CA cert (path? access rights?).
>>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: Forwarding request 
>>> to dogtag-ipa-renew-agent
>>> Oct 11 06:00:17 ipasrv dogtag-ipa-ca-renew-agent-submit: 
>>> dogtag-ipa-renew-agent returned 3
>>> Oct 11 06:00:17 ipasrv certmonger[131018]: 2018-10-11 06:00:17 [131018] 
>>> Error 77 connecting to https://ipasrv:8443/ca/agent/ca/profileReview: 
>>> Problem with the SSL CA cert (path? access rights?).
>>>
>> Ok, I think I know what is going on. This is Ubuntu which AFAIK still
>> lacks nss-pem. That is probably why it can't connect to renew the certs.
>>
>> I don't know if there is a workaround. Timo, do you know?
> Ubuntu 18.04 and up have libnsspem, and certmonger depends on it. I've
> never tested cert renewal though.
>

Does that mean, I'm screwed? What options do