Rob Crittenden via FreeIPA-users:
> Klaus Vink Slott via FreeIPA-users wrote:
>> Today Rob Crittenden wrote:
>>> Klaus Vink Slott via FreeIPA-users wrote:
>>>> Den 01/05/2019 kl. 21.48 skrev Rob Crittenden via FreeIPA-users:
>>>>> Klaus Vink Slott via FreeIPA-users wrote:
>>>>>> Have had a small FreeIPA setup running for some time, but today I
was unable to login at the web-gui on the master. It was possible to login at the replica
but if try to delete a host I get:
>>>>>>
>>>>>> cannot connect to
'https://ipa.int.vink-slott.dk:443/ca/rest/certs/search?size=2147483647': [SSL:
CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:877)
>>>>>>
>>>>>> Indeed if I run a getcert list -c IPA on the master, one
certificate is expired.
>>>>>> Request ID '20190302094604':
>>>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN
>>>>>> stuck: yes
>>>>>> key pair storage:
type=FILE,location='/var/lib/ipa/private/httpd.key'
>>>>>> certificate:
type=FILE,location='/var/lib/ipa/certs/httpd.crt'
>>>>>> CA: IPA
>>>>>> issuer: CN=Certificate Authority,O=INT.VINK-SLOTT.DK
>>>>>> subject: CN=ipa.int.vink-slott.dk,O=INT.VINK-SLOTT.DK
>>>>>> expires: 2019-04-22 15:33:08 CEST
>>>>>> dns: ipa.int.vink-slott.dk
>>>>>> key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>>>>> eku: id-kp-serverAuth,id-kp-clientAuth
>>>>>> pre-save command:
>>>>>> post-save command:
/usr/libexec/ipa/certmonger/restart_httpd
>>>>>> track: yes
>>>>>> auto-renew: yes
>>>>>>
>>>>>> All other certificates is valid and status: MONITORING
>>>>>>
>>>>>> I tried different measures based on google searches and old
entries on this list. But all I have accomplished is to change the state to:
>>>>>> Request ID '20190302094604':
>>>>>> status: NEED_KEYINFO_READ_PIN
>>>>>> stuck: yes
>>>>>> key pair storage:
type=FILE,location='/var/lib/ipa/private/httpd.key',pin set
>>>>>>
>>>>>> At this state I am not sure that I added the correct pin. - And
why this is suddenly a problem.
>>>>>
>>>>> It depends very much on what version of IPA you are running, perhaps
the
>>>>> distro, and what you did to get the tracking into this state.
>>>>>
>>>>
>>>> It is freeipa-server-4.7.2-1.1.fc28.x86_64 on a fully patched Fedora 28
>>>>
>>>> What I tried so far (rebuild from memory and bash-history):
>>>>
>>>> # ipa-getcert resubmit -i 20190302094604
>>>> - result:
>>>> status: NEWLY_ADDED_NEED_KEYINFO_READ_PIN -> NEED_KEYINFO_READ_PIN
>>>>
>>>> Then I followed
https://access.redhat.com/solutions/3939431
>>>> - no change
>>>>
>>>> Then I located pin in /etc/pki/pki-tomcat/password.conf and
>>>> /etc/httpd/conf/password.conf and tried to add these like this:
>>>> # getcert start-tracking -i 20190302094604 -P \
>>>> # [long-number from internal=]
>>>> # ipa-getcert resubmit -i 20190302094604
>>>> - result: key pair storage now have " ,pin set"
>>>>
>>>> # getcert start-tracking -i 20190302094604 -P \
>>>> # [hexstring from internal:]
>>>> - result: key pair storage now have " ,pin set"
>>>>
>>>
>>> Those are the wrong passwords. The Apache password file should be
>>> /var/lib/ipa/passwds/ipa.int.vink-slott.dk-443-RSA based on the output
>>> you provided.
>> I had the suspicion that they were wrong. Thanks for pointing to the
>> correct file.
>>
>>> I'd suggest to stop tracking and start over using:
>>>
>>> # ipa-getcert stop-tracking -f /var/lib/ipa/certs/httpd.crt
>>> # ipa-getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k
>>> /var/lib/ipa/private/httpd.key -p
>>> /var/lib/ipa/passwds/ipa.int.vink-slott.dk-443-RSA -C
>>> /usr/libexec/ipa/certmonger/restart_httpd
>> So I did and now I got:
>>
>> Request ID '20190502160024':
>> status: MONITORING
>> ca-error: Unable to determine principal name for signing request.
>> stuck: no
>> key pair storage:
>>
type=FILE,location='/var/lib/ipa/private/httpd.key',pinfile='/var/lib/ipa/passwds/ipa.int.vink-slott.dk-443-RSA'
>> certificate: type=FILE,location='/var/lib/ipa/certs/httpd.crt'
>> CA: IPA
>> issuer: CN=Certificate Authority,O=INT.VINK-SLOTT.DK
>> subject: CN=ipa.int.vink-slott.dk,O=INT.VINK-SLOTT.DK
>> expires: 2019-04-22 15:33:08 CEST
>> dns: ipa.int.vink-slott.dk
>> key usage:
>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>> eku: id-kp-serverAuth,id-kp-clientAuth
>> pre-save command:
>> post-save command: /usr/libexec/ipa/certmonger/restart_httpd
>> track: yes
>> auto-renew: yes
>>
>>> Then you'll need to go back in time to renew the certificate.
>> Moving time back and resubmitting (according to the procedure in
>>
https://access.redhat.com/solutions/3939431) does not change anything.
>>
>
> My bad, I missed the principal. This should fix it:
>
> # ipa-getcert start-tracking -K
> HTTP/ipa.int.vink-slott.dk(a)INT.VINK-SLOTT.DK -i 20190502160024
That (and a detour back in time) solved my problem. Everything is now
back to normal operation.
Thanks a lot for for helping me out :-)
Although I do wonder how this could happen. I may consider adding a
small certificate monitor to my snmp setup.
You'd be monitoring a monitor :-)
But really, we're working on a health checking tool that will catch
things like bad tracking, give warnings of upcoming expiration, etc.
More formal announcement will be soon-ish.
rob