[Freeipa-users] Re: Certificates renewing with the wrong Subject

[Rob Crittenden via FreeIPA-users]

Roderick Johnstone via FreeIPA-users wrote:
> On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote:
>> Roderick Johnstone via FreeIPA-users wrote:
>>> On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote:
 Roderick Johnstone via FreeIPA-users wrote:
> On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote:
>> Roderick Johnstone via FreeIPA-users wrote:
>>> On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote:
 Roderick Johnstone via FreeIPA-users wrote:
> Hi
>
> Our freeipa certificates need to be renewed due to passing their
> expiry
> dates.
>
> While some certificates have renewed ok, the ipaCert and
> auditSigningCert are renewing but the new certificates have the
> wrong
> Subject.
>
> Environment is:
> serverA (CRL, first, master) RHEL 7.3, ipa 4.4
> serverB (replica) RHEL 7.3, ipa 4.4
> serverC (replica) RHEL 7.4, ipa 4.5
>
> Once there are renewed certificates with the wrong Subject
> present,
> there are various problems with renewing the remaining
> certificates,
> which I think might be related to the bad Subject:
>
> 1) When just ipaCert has the wrong subject no further renewals
> happen
>
> 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd
> service will not start and no further renewals happen.
>
> I've been round the following loop many times on ServerA, our
> first
> master:
>
> 1) Restore good certificates from backup
> 2) Put the clock back to a time when certificates are all valid
> 3) Resubmit certificates for renewal
>
> Each time the ipaCert renews it has the same wrong Subject. The
> wrong
> Subject includes the host name of one of our ipa client systems.
>
> Each time the auditSigningCert renews it has the same wrong
> Subject
> but
> a different subject to the ipaCert. The wrong Subject in this case
> includes the host name of a system which has never been an ipa
> client,
> but might have been added and removed with ipa host-add and ipa
> host-del
> for testing something, a while ago.
>
> As far as I can see, the "cert_subject" is set correctly in the
> file
> /var/lib/certmonger/ until the point at which the
> certificate is actually renewed.
>
> I'd be very grateful for some pointers as to which configuration
> options
> and logs to check through to resolve this problem on our
> production
> system.
>
> If its of any relevance we did change which server is the first
> master
> some time ago.

 I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see
 what
 the subject is.
>>>
>>> I'm not seeing any obvious CSR fields in the
>>> /etc/pki/pki-tomcat/ca/CS.cfg file.
>>
>> foo.bar.certreq=
>>
>>> The CSR in the certmonger requests file for the auditSigningCert
>>> seems
>>> to be showing with the correct Subject. This is different from
>>> the bad
>>> subject showing in the requests file field:
>>> cert_subject=
>>
>> The value of cert_subject comes from the issued certificate.
>>
>>> and the Subject which is showing in the 'getcert list' output
>>> (which is
>>> the same as that in the cert_subject= field.>
>>> I'm not quite sure what this all means.
>>
>> It is displayed from the data within the tracked certmonger request.
>>
>> certmonger logs to syslog so you can check there or you can stop the
>> process and run it manually with: certmonger -n -d 9 2>&1 | tee
>> certmonger.log
>>
>> That will provide a lot of debugging output that may show what is
>> going on.
>
> I've restored certificate databases from backup and put the clock back
> to a time when certificates are valid and renewed the ocspSigining
> certificate with:
> getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302
>
> (I've previously tried without the -N with similar results)
>
> What I am seeing in the certmonger logs is:
>
>
> 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert
> cert-pki-ca'.
> 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert
> cert-pki-ca' to public key.
> 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert
> cert-pki-ca".
> 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert
> cert-pki-ca" in token "NSS Certificate DB" in database
> "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401.
> 2017-10-23 00:05:28 [442] Located 

[Freeipa-users] Re: Howto renew certificates with external CA?

[Harald.Husemann--- via FreeIPA-users]

Hello Flo,

thanks for your answer, and for the explanation of the certutil output. I have 
tried your suggestion, first with sudo:

hhuseman@mat-ipa-master-1:~$ sudo kinit -kt /etc/krb5.keytab
[sudo] password for hhuseman:
Sorry, try again.
[sudo] password for hhuseman:
Sorry, try again.
[sudo] password for hhuseman:
sudo: 2 incorrect password attempts

I'm quite sure my password is correct, so it seems there's something broken 
here also, since sudo worked before the certificate update. My next try was 
running the command as root:

hhuseman@mat-ipa-master-1:~$ su -
Password:
root@mat-ipa-master-1:~$ kinit -kt /etc/krb5.keytab
root@mat-ipa-master-1:~$ exit
logout

As you see, there is no output at all, so I tried it again with -V:

root@mat-ipa-master-1:~$ kinit -V -kt /etc/krb5.keytab
Using existing cache: persistent:0:krb_ccache_VPUg94b
Using principal: host/mat-ipa-master-1.materna-com...@materna-com.de
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5
root@mat-ipa-master-1:~$

I have also re-checked the certificate which is issued by the HTTPS-Server in 
my browser, it is still the old one. 
And, I've tried to get the list of certificates with ipa-getcert:

root@mat-ipa-master-1:~$ ipa-getcert list
Number of certificates and requests being tracked: 5.
Request ID '20170303080146':
status: CA_UNREACHABLE
ca-error: Server at https://mat-ipa-master-1.materna-com.de/ipa/xml 
failed request, will retry: -504 (libcurl failed to execute the HTTP POST 
transaction, explaining:  Peer's Certificate has expired.).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/dirsrv/slapd-MATERNA-COM-DE/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS
 Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=MATERNA-COM.DE
subject: CN=mat-ipa-master-1.materna-com.de,O=MATERNA-COM.DE
expires: 2018-01-13 14:45:00 UTC
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 
MATERNA-COM-DE
track: yes
auto-renew: yes

Interesting, since the date was still reset to January 11th, so, even the old 
certificate should be valid:
root@mat-ipa-master-1:~$ date
Thu Jan 11 05:22:21 CET 2018

Nevertheless, I've set the date to actual time by sync'ing it to our NTP-Server:

root@mat-ipa-master-1:~$ ntpdate omcix
24 Jan 19:09:00 ntpdate[32699]: step time server 172.30.96.6 offset 
1172766.789568 sec
root@mat-ipa-master-1:~$ date
Wed Jan 24 19:09:06 CET 2018

But, ipa-getcert list is still falling:

root@mat-ipa-master-1:~$ ipa-getcert list
Number of certificates and requests being tracked: 5.
Request ID '20170303080146':
status: NEED_TO_SUBMIT
ca-error: Server at https://mat-ipa-master-1.materna-com.de/ipa/xml 
failed request, will retry: -504 (libcurl failed to execute the HTTP POST 
transaction, explaining:  Peer's Certificate has expired.).
stuck: no
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/dirsrv/slapd-MATERNA-COM-DE/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-MATERNA-COM-DE',nickname='Server-Cert',token='NSS
 Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=MATERNA-COM.DE
subject: CN=mat-ipa-master-1.materna-com.de,O=MATERNA-COM.DE
expires: 2018-01-13 14:45:00 UTC
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 
MATERNA-COM-DE
track: yes
auto-renew: yes
root@mat-ipa-master-1:~$

To ensure everything's running I've issued an ipactl:

root@mat-ipa-master-1:~$ ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: STOPPED
ipa-otpd Service: RUNNING
ipa: INFO: The ipactl command was successful
root@mat-ipa-master-1:~$

So it seems everything's ok except of the PKI, I've tried to restart it, but it 
fails:

root@mat-ipa-master-1:~$ ipactl start pki-tomcatd
You must specify one action
root@mat-ipa-master-1:~$ ipactl start
Existing service file detected!
Assuming stale, cleaning and proceeding
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting ipa_memcached Service
Starting httpd Service
Starting ipa-custodia Service
Starting pki-tomcatd Service
Failed to start pki-tomcatd Service
Shutting down
Hint: You can use --ignore-service-failure option for 

[Freeipa-users] Re: Certificates renewing with the wrong Subject

[Roderick Johnstone via FreeIPA-users]

On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

Hi

Our freeipa certificates need to be renewed due to passing their
expiry
dates.

While some certificates have renewed ok, the ipaCert and
auditSigningCert are renewing but the new certificates have the
wrong
Subject.

Environment is:
serverA (CRL, first, master) RHEL 7.3, ipa 4.4
serverB (replica) RHEL 7.3, ipa 4.4
serverC (replica) RHEL 7.4, ipa 4.5

Once there are renewed certificates with the wrong Subject present,
there are various problems with renewing the remaining certificates,
which I think might be related to the bad Subject:

1) When just ipaCert has the wrong subject no further renewals
happen

2) When auditSigningCert has the wrong subject the ipa pki-tomcatd
service will not start and no further renewals happen.

I've been round the following loop many times on ServerA, our first
master:

1) Restore good certificates from backup
2) Put the clock back to a time when certificates are all valid
3) Resubmit certificates for renewal

Each time the ipaCert renews it has the same wrong Subject. The
wrong
Subject includes the host name of one of our ipa client systems.

Each time the auditSigningCert renews it has the same wrong Subject
but
a different subject to the ipaCert. The wrong Subject in this case
includes the host name of a system which has never been an ipa
client,
but might have been added and removed with ipa host-add and ipa
host-del
for testing something, a while ago.

As far as I can see, the "cert_subject" is set correctly in the file
/var/lib/certmonger/ until the point at which the
certificate is actually renewed.

I'd be very grateful for some pointers as to which configuration
options
and logs to check through to resolve this problem on our production
system.

If its of any relevance we did change which server is the first
master
some time ago.


I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what
the subject is.


I'm not seeing any obvious CSR fields in the
/etc/pki/pki-tomcat/ca/CS.cfg file.


foo.bar.certreq=


The CSR in the certmonger requests file for the auditSigningCert seems
to be showing with the correct Subject. This is different from the bad
subject showing in the requests file field:
cert_subject=


The value of cert_subject comes from the issued certificate.


and the Subject which is showing in the 'getcert list' output
(which is
the same as that in the cert_subject= field.>
I'm not quite sure what this all means.


It is displayed from the data within the tracked certmonger request.

certmonger logs to syslog so you can check there or you can stop the
process and run it manually with: certmonger -n -d 9 2>&1 | tee
certmonger.log

That will provide a lot of debugging output that may show what is
going on.


I've restored certificate databases from backup and put the clock back
to a time when certificates are valid and renewed the ocspSigining
certificate with:
getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302

(I've previously tried without the -N with similar results)

What I am seeing in the certmonger logs is:


2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'.
2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert
cert-pki-ca" in token "NSS Certificate DB" in database
"/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401.
2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'.
2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'.
2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:39 [581] Found a certificate with the same nickname but
different subject, removing certificate "ocspSigningCert cert-pki-ca"
with subject "CN=OCSP Subsystem,O=".
2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert
cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca".
2017-10-23 00:05:39 [583] Located the certificate "ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:39 [48576] Adding hook
"/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert
cert-pki-ca"" (0).
2017-10-23 00:10:43 [942] 0x1d Certificate named "ocspSigningCert
cert-pki-ca" in token "NSS Certificate DB" in database
"/etc/pki/pki-tomcat/alias" issued by CA and saved.

[Freeipa-users] Re: Howto renew certificates with external CA?

[Florence Blanc-Renaud via FreeIPA-users]

On 01/24/2018 12:35 PM, Harald Husemann via FreeIPA-users wrote:

Hello IPA-experts,

we are running FreeIPA version 4.4.0 with an external CA (our own one), 
everything was working fine until the CA certificate expired which 
happened at January 13th.
Since i was on vacation and the basic functions were still available 
no-one created a new certificate, so, it's now my task.
As explained in 
https://www.freeipa.org/page/Howto/CA_Certificate_Renewal, I've reset 
the time to January 10th, created a new certificate which is valid from 
2017 to 2023, and installed it with ipa-cacert-manage.
Afterwards, I did an ipa-certupdate, the server certificates were 
updated and the cert8.db in /etc/httpd/alias contains the new valid CA. 
But, the expiration date of the certificate itself is still January 
13th, so, the certificate is still expired:


root@mat-ipa-master-1:~$ /usr/bin/certutil -d /etc/httpd/alias -L -n 
"MATERNA-COM.DE IPA CA"

Certificate:
     Data:
     Version: 3 (0x2)
     Serial Number: 36 (0x24)
     Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
     Issuer: "E=oc...@materna.de,CN=Materna OC CA,OU=OC RZ,O=Materna 
GmbH,

     L=Dortmund,ST=NRW,C=DE"
     Validity:
     Not Before: Mon Jan 23 14:45:00 2017
     Not After : Mon Jan 23 14:45:00 2023
     Subject: "CN=Certificate Authority,O=MATERNA-COM.DE"
    (...)
     Certificate Trust Flags:
     SSL Flags:
     Valid CA
     Trusted CA
     Trusted Client CA
     Email Flags:
     Valid CA
     Trusted CA
     Object Signing Flags:
     Valid CA
     Trusted CA

Certificate:
     Data:
     Version: 3 (0x2)
     Serial Number: 23 (0x17)
     Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
     Issuer: "E=oc...@materna.de,CN=Materna OC CA,OU=OC RZ,O=Materna 
GmbH,

     L=Dortmund,ST=NRW,C=DE"
     Validity:
     Not Before: Fri Jan 13 14:45:00 2017
     Not After : Sat Jan 13 14:45:00 2018
     Subject: "CN=Certificate Authority,O=MATERNA-COM.DE"
     (...)

root@mat-ipa-master-1:~$

Hi,

in the above output we can see 2 different certificates for 
"CN=Certificate Authority,O=MATERNA-COM.DE", which is an expected 
behavior: the database still contains the old one (Not After: Sat Jan 13 
14:45:00 2018) but also contains the new one (Not After : Mon Jan 23 
14:45:00 2023). So from this point of view, IPA CA cert was properly 
renewed and distributed to the httpd NSS database.



I have only checked this one, but I'd suppose the others are also not 
updated. AFAIK certmonger is responsible the renewal, so, I've restarted 
it and hoped it would grab my certificate and renew it - but it seems 
there is a problem, journalctl -u certmonger gives


Jan 24 11:22:43 mat-ipa-master-1.materna-com.de systemd[1]: Starting 
Certificate monitoring and PKI enrollment...
Jan 24 11:22:44 mat-ipa-master-1.materna-com.de systemd[1]: Started 
Certificate monitoring and PKI enrollment.
Jan 24 11:22:48 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:22:48 [1026] Error setting up ccache for "host" service on 
client using default keytab: Cannot contact any KDC for realm 
'MATERNA-COM.DE'.
Jan 24 11:22:48 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:22:48 [1026] Error setting up ccache for "host" service on 
client using default keytab: Cannot contact any KDC for realm 
'MATERNA-COM.DE'.
Jan 24 11:22:58 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:22:58 [1026] Error 7 connecting to 
https://mat-ipa-master-1.materna-com.de:8443/ca/agent/ca/profileReview: 
Couldn't connect to server.
Jan 24 11:23:00 mat-ipa-master-1.materna-com.de 
dogtag-ipa-ca-renew-agent-submit[2282]: Traceback (most recent call last):
File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 
511, in 

sys.exit(main())
File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 
490, in main

ipautil.kinit_keytab(principal, paths.KRB5_KEYTAB, ccache_filename)
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1314, 
in kinit_keytab

cred = gssapi.Credentials(name=name, store=store, usage='initiate')
File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 64, in 
__new__

store=store)
File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 148, in 
acquire

usage)
File "ext_cred_store.pyx", line 182, in 
gssapi.raw.ext_cred_store.acquire_cred_from 
(gssapi/raw/ext_cred_store.c:1732)
GSSError: Major (851968): Unspecified GSS failure.  Minor code may 
provide more information, Minor (2529639068): Cannot contact any KDC for 
realm 'MA
Jan 24 11:23:00 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:23:00 [1026] Internal error


The traceback is generated by the helper launched to renew IPA CA. This 
helper authenticates using /etc/krb5.keytab but according to the traces, 
was unable to reach 

[Freeipa-users] Re: Certificates renewing with the wrong Subject

[Rob Crittenden via FreeIPA-users]

Roderick Johnstone via FreeIPA-users wrote:
> On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote:
>> Roderick Johnstone via FreeIPA-users wrote:
>>> On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote:
 Roderick Johnstone via FreeIPA-users wrote:
> On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote:
>> Roderick Johnstone via FreeIPA-users wrote:
>>> Hi
>>>
>>> Our freeipa certificates need to be renewed due to passing their
>>> expiry
>>> dates.
>>>
>>> While some certificates have renewed ok, the ipaCert and
>>> auditSigningCert are renewing but the new certificates have the
>>> wrong
>>> Subject.
>>>
>>> Environment is:
>>> serverA (CRL, first, master) RHEL 7.3, ipa 4.4
>>> serverB (replica) RHEL 7.3, ipa 4.4
>>> serverC (replica) RHEL 7.4, ipa 4.5
>>>
>>> Once there are renewed certificates with the wrong Subject present,
>>> there are various problems with renewing the remaining certificates,
>>> which I think might be related to the bad Subject:
>>>
>>> 1) When just ipaCert has the wrong subject no further renewals
>>> happen
>>>
>>> 2) When auditSigningCert has the wrong subject the ipa pki-tomcatd
>>> service will not start and no further renewals happen.
>>>
>>> I've been round the following loop many times on ServerA, our first
>>> master:
>>>
>>> 1) Restore good certificates from backup
>>> 2) Put the clock back to a time when certificates are all valid
>>> 3) Resubmit certificates for renewal
>>>
>>> Each time the ipaCert renews it has the same wrong Subject. The
>>> wrong
>>> Subject includes the host name of one of our ipa client systems.
>>>
>>> Each time the auditSigningCert renews it has the same wrong Subject
>>> but
>>> a different subject to the ipaCert. The wrong Subject in this case
>>> includes the host name of a system which has never been an ipa
>>> client,
>>> but might have been added and removed with ipa host-add and ipa
>>> host-del
>>> for testing something, a while ago.
>>>
>>> As far as I can see, the "cert_subject" is set correctly in the file
>>> /var/lib/certmonger/ until the point at which the
>>> certificate is actually renewed.
>>>
>>> I'd be very grateful for some pointers as to which configuration
>>> options
>>> and logs to check through to resolve this problem on our production
>>> system.
>>>
>>> If its of any relevance we did change which server is the first
>>> master
>>> some time ago.
>>
>> I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what
>> the subject is.
>
> I'm not seeing any obvious CSR fields in the
> /etc/pki/pki-tomcat/ca/CS.cfg file.

 foo.bar.certreq=

> The CSR in the certmonger requests file for the auditSigningCert seems
> to be showing with the correct Subject. This is different from the bad
> subject showing in the requests file field:
> cert_subject=

 The value of cert_subject comes from the issued certificate.

> and the Subject which is showing in the 'getcert list' output
> (which is
> the same as that in the cert_subject= field.>
> I'm not quite sure what this all means.

 It is displayed from the data within the tracked certmonger request.

 certmonger logs to syslog so you can check there or you can stop the
 process and run it manually with: certmonger -n -d 9 2>&1 | tee
 certmonger.log

 That will provide a lot of debugging output that may show what is
 going on.
>>>
>>> I've restored certificate databases from backup and put the clock back
>>> to a time when certificates are valid and renewed the ocspSigining
>>> certificate with:
>>> getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302
>>>
>>> (I've previously tried without the -N with similar results)
>>>
>>> What I am seeing in the certmonger logs is:
>>>
>>>
>>> 2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'.
>>> 2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert
>>> cert-pki-ca' to public key.
>>> 2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert
>>> cert-pki-ca".
>>> 2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert
>>> cert-pki-ca" in token "NSS Certificate DB" in database
>>> "/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401.
>>> 2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'.
>>> 2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert
>>> cert-pki-ca' to public key.
>>> 2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert
>>> cert-pki-ca".
>>> 2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'.
>>> 2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert
>>> cert-pki-ca' to public key.
>>> 2017-10-23 

[Freeipa-users] Re: Request for input on installing IPA onto ARM/SoC boards

[Aljaž Srebrnič via FreeIPA-users]

> On 24 Jan 2018, at 15:17, Rob Crittenden  > wrote:
> 
> This is great feedback, thanks.
> 
> You might be able to get away with an IPA client in this case. sssd will
> cache credentials. This wouldn't cover the case where someone hasn't
> used the door yet, power goes off, and they need to open it though.

Yes, that is the backup plan in case I can’t get the replica to work with the 
very limited amount of RAM I have (either 256 or 512 MB). It’s a fun project 
for my hackerspace so the cost of failure is not that high.

> 
> I suspect that running without a CA is much more viable, but 389-ds can
> be resource-intesive as well depending on how many entries you have.

I’m expecting we won’t have more than 150 users, so it shouldn’t be that big of 
a problem.


--
Aljaž Srebrnič a.k.a g5pw
My public key:  https://g5pw.me/key 
Key fingerprint = 2109 8131 60CA 01AF 75EC  01BF E140 E1EE A54E E677

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Request for input on installing IPA onto ARM/SoC boards

[Rob Crittenden via FreeIPA-users]

Aljaž Srebrnič wrote:
>> On 23 Jan 2018, at 14:44, Rob Crittenden via FreeIPA-users
>> > > wrote:
>>
>> But why?
>>
>> Is it because the hardware is so cheap? Is it better/easier/cheaper than
>> running it in a VM on an existing box? Is it merely for the "fun" factor
>> (and I'm not disparaging it, I do lots of things just to see if it can
>> be done).
>>
>> rob
> 
> There are a couple of applications actually, I’m currently trying to
> build an access control system based on an IPA replica that runs *on*
> the door, using the existing replication mechanisms. This way, even if
> networking is down, as long as the door has power, I can open it.

This is great feedback, thanks.

You might be able to get away with an IPA client in this case. sssd will
cache credentials. This wouldn't cover the case where someone hasn't
used the door yet, power goes off, and they need to open it though.

I suspect that running without a CA is much more viable, but 389-ds can
be resource-intesive as well depending on how many entries you have.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Howto renew certificates with external CA?

[Harald Husemann via FreeIPA-users]

Hello IPA-experts,

we are running FreeIPA version 4.4.0 with an external CA (our own one), 
everything was working fine until the CA certificate expired which 
happened at January 13th.
Since i was on vacation and the basic functions were still available 
no-one created a new certificate, so, it's now my task.
As explained in 
https://www.freeipa.org/page/Howto/CA_Certificate_Renewal, I've reset 
the time to January 10th, created a new certificate which is valid from 
2017 to 2023, and installed it with ipa-cacert-manage.
Afterwards, I did an ipa-certupdate, the server certificates were 
updated and the cert8.db in /etc/httpd/alias contains the new valid CA. 
But, the expiration date of the certificate itself is still January 
13th, so, the certificate is still expired:


root@mat-ipa-master-1:~$ /usr/bin/certutil -d /etc/httpd/alias -L -n 
"MATERNA-COM.DE IPA CA"

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 36 (0x24)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "E=oc...@materna.de,CN=Materna OC CA,OU=OC RZ,O=Materna 
GmbH,

L=Dortmund,ST=NRW,C=DE"
Validity:
Not Before: Mon Jan 23 14:45:00 2017
Not After : Mon Jan 23 14:45:00 2023
Subject: "CN=Certificate Authority,O=MATERNA-COM.DE"
   (...)
Certificate Trust Flags:
SSL Flags:
Valid CA
Trusted CA
Trusted Client CA
Email Flags:
Valid CA
Trusted CA
Object Signing Flags:
Valid CA
Trusted CA

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 23 (0x17)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "E=oc...@materna.de,CN=Materna OC CA,OU=OC RZ,O=Materna 
GmbH,

L=Dortmund,ST=NRW,C=DE"
Validity:
Not Before: Fri Jan 13 14:45:00 2017
Not After : Sat Jan 13 14:45:00 2018
Subject: "CN=Certificate Authority,O=MATERNA-COM.DE"
(...)

root@mat-ipa-master-1:~$


I have only checked this one, but I'd suppose the others are also not 
updated. AFAIK certmonger is responsible the renewal, so, I've restarted 
it and hoped it would grab my certificate and renew it - but it seems 
there is a problem, journalctl -u certmonger gives


Jan 24 11:22:43 mat-ipa-master-1.materna-com.de systemd[1]: Starting 
Certificate monitoring and PKI enrollment...
Jan 24 11:22:44 mat-ipa-master-1.materna-com.de systemd[1]: Started 
Certificate monitoring and PKI enrollment.
Jan 24 11:22:48 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:22:48 [1026] Error setting up ccache for "host" service on 
client using default keytab: Cannot contact any KDC for realm 
'MATERNA-COM.DE'.
Jan 24 11:22:48 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:22:48 [1026] Error setting up ccache for "host" service on 
client using default keytab: Cannot contact any KDC for realm 
'MATERNA-COM.DE'.
Jan 24 11:22:58 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:22:58 [1026] Error 7 connecting to 
https://mat-ipa-master-1.materna-com.de:8443/ca/agent/ca/profileReview: 
Couldn't connect to server.
Jan 24 11:23:00 mat-ipa-master-1.materna-com.de 
dogtag-ipa-ca-renew-agent-submit[2282]: Traceback (most recent call last):
File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 
511, in 

sys.exit(main())
File "/usr/libexec/certmonger/dogtag-ipa-ca-renew-agent-submit", line 
490, in main

ipautil.kinit_keytab(principal, paths.KRB5_KEYTAB, ccache_filename)
File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1314, 
in kinit_keytab

cred = gssapi.Credentials(name=name, store=store, usage='initiate')
File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 64, in 
__new__

store=store)
File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 148, in 
acquire

usage)
File "ext_cred_store.pyx", line 182, in 
gssapi.raw.ext_cred_store.acquire_cred_from 
(gssapi/raw/ext_cred_store.c:1732)
GSSError: Major (851968): Unspecified GSS failure.  Minor code may 
provide more information, Minor (2529639068): Cannot contact any KDC for 
realm 'MA
Jan 24 11:23:00 mat-ipa-master-1.materna-com.de certmonger[1026]: 
2018-01-24 11:23:00 [1026] Internal error


Any help is greatly appreciated since I'm stuck here... If it helps, I 
have a clean backup of the IPA master which was written yesterday 
evening, so, I can use this one to "start over" if I've already mixed up 
things.


Thanks and kind regards from Germany,

Harald
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Certificates renewing with the wrong Subject

[Roderick Johnstone via FreeIPA-users]

On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote:

Roderick Johnstone via FreeIPA-users wrote:

Hi

Our freeipa certificates need to be renewed due to passing their
expiry
dates.

While some certificates have renewed ok, the ipaCert and
auditSigningCert are renewing but the new certificates have the wrong
Subject.

Environment is:
serverA (CRL, first, master) RHEL 7.3, ipa 4.4
serverB (replica) RHEL 7.3, ipa 4.4
serverC (replica) RHEL 7.4, ipa 4.5

Once there are renewed certificates with the wrong Subject present,
there are various problems with renewing the remaining certificates,
which I think might be related to the bad Subject:

1) When just ipaCert has the wrong subject no further renewals happen

2) When auditSigningCert has the wrong subject the ipa pki-tomcatd
service will not start and no further renewals happen.

I've been round the following loop many times on ServerA, our first
master:

1) Restore good certificates from backup
2) Put the clock back to a time when certificates are all valid
3) Resubmit certificates for renewal

Each time the ipaCert renews it has the same wrong Subject. The wrong
Subject includes the host name of one of our ipa client systems.

Each time the auditSigningCert renews it has the same wrong Subject
but
a different subject to the ipaCert. The wrong Subject in this case
includes the host name of a system which has never been an ipa client,
but might have been added and removed with ipa host-add and ipa
host-del
for testing something, a while ago.

As far as I can see, the "cert_subject" is set correctly in the file
/var/lib/certmonger/ until the point at which the
certificate is actually renewed.

I'd be very grateful for some pointers as to which configuration
options
and logs to check through to resolve this problem on our production
system.

If its of any relevance we did change which server is the first master
some time ago.


I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger to see what
the subject is.


I'm not seeing any obvious CSR fields in the
/etc/pki/pki-tomcat/ca/CS.cfg file.


foo.bar.certreq=


The CSR in the certmonger requests file for the auditSigningCert seems
to be showing with the correct Subject. This is different from the bad
subject showing in the requests file field:
cert_subject=


The value of cert_subject comes from the issued certificate.


and the Subject which is showing in the 'getcert list' output (which is
the same as that in the cert_subject= field.>
I'm not quite sure what this all means.


It is displayed from the data within the tracked certmonger request.

certmonger logs to syslog so you can check there or you can stop the
process and run it manually with: certmonger -n -d 9 2>&1 | tee
certmonger.log

That will provide a lot of debugging output that may show what is
going on.


I've restored certificate databases from backup and put the clock back
to a time when certificates are valid and renewed the ocspSigining
certificate with:
getcert resubmit -N "CN=OCSP Subsystem,O=" -i 20161124081302

(I've previously tried without the -N with similar results)

What I am seeing in the certmonger logs is:


2017-10-23 00:05:28 [438] Located the key 'ocspSigningCert cert-pki-ca'.
2017-10-23 00:05:28 [438] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:28 [439] Located the certificate "ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:28 [440] 0x1d Certificate named "ocspSigningCert
cert-pki-ca" in token "NSS Certificate DB" in database
"/etc/pki/pki-tomcat/alias" will not be valid after 20171025122401.
2017-10-23 00:05:28 [442] Located the key 'ocspSigningCert cert-pki-ca'.
2017-10-23 00:05:28 [442] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:28 [443] Located the certificate "ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:28 [444] Located the key 'ocspSigningCert cert-pki-ca'.
2017-10-23 00:05:28 [444] Converted private key 'ocspSigningCert
cert-pki-ca' to public key.
2017-10-23 00:05:39 [581] Found a certificate with the same nickname but
different subject, removing certificate "ocspSigningCert cert-pki-ca"
with subject "CN=OCSP Subsystem,O=".
2017-10-23 00:05:39 [581] Imported certificate "ocspSigningCert
cert-pki-ca", got nickname "ocspSigningCert cert-pki-ca".
2017-10-23 00:05:39 [583] Located the certificate "ocspSigningCert
cert-pki-ca".
2017-10-23 00:05:39 [48576] Adding hook
"/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert
cert-pki-ca"" (0).
2017-10-23 00:10:43 [942] 0x1d Certificate named "ocspSigningCert
cert-pki-ca" in token "NSS Certificate DB" in database
"/etc/pki/pki-tomcat/alias" issued by CA and saved.

I now have a date valid ocspSigningCertificate, but with the wrong
subject, and a broken certificate system 

[Freeipa-users] Re: Request for input on installing IPA onto ARM/SoC boards

[Aljaž Srebrnič via FreeIPA-users]

> On 23 Jan 2018, at 14:44, Rob Crittenden via FreeIPA-users 
>  > wrote:
> 
> But why?
> 
> Is it because the hardware is so cheap? Is it better/easier/cheaper than
> running it in a VM on an existing box? Is it merely for the "fun" factor
> (and I'm not disparaging it, I do lots of things just to see if it can
> be done).
> 
> rob


There are a couple of applications actually, I’m currently trying to build an 
access control system based on an IPA replica that runs *on* the door, using 
the existing replication mechanisms. This way, even if networking is down, as 
long as the door has power, I can open it.

--
Aljaž Srebrnič a.k.a g5pw
My public key:  https://g5pw.me/key 
Key fingerprint = 2109 8131 60CA 01AF 75EC  01BF E140 E1EE A54E E677

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: user_add post_callback doesn't seem to be called.

[Alexander Bokovoy via FreeIPA-users]

On ti, 23 tammi 2018, Bryce Larson via FreeIPA-users wrote:

I thought I should let everyone know what ended up happening with this.  It 
turns out
that the script is now run as the ipaapi user instead of as root (like it 
either used to
or I thought it used to).  We changed permissions on some files that the script 
needed
and now it works again.

Ok, good to know. IPA framework never ran as root as it was part of
apache process tree and that ran as 'httpd' user in past. With 4.5 and
later we implemented privilege separation where the framework runs under
'ipaapi' user and the rest of Apache has no access to its data while
'ipaapi' has no access to the Apache's keytab -- neither Apache itself,
gssproxy handles the magic.

You can read more details at https://vda.li/en/docs/freeipa-debug-privsep/



On Fri, Jan 12, 2018 at 08:51:38PM +0200, Alexander Bokovoy wrote:

On pe, 12 tammi 2018, Bryce Larson via FreeIPA-users wrote:
> We have function that are supposed to be called in a plugin from a 
post_callback
>
> It's registered with:
>
> user.user_add.register_post_callback(useradd_postcallback)
>
> The plugin is at 
/usr/lib/python2.7/site-packages/ipaserver/plugins/csAccount.py
>
> It doesn't seem to be called at all, it used to.  I'm not sure if it
> was upgrading from 4.3 to 4.4, or from 4.4 to 4.5 that it stopped
> working, but I think it was the upgrade from 4.4 to 4.5.  I'm pretty
> sure the pre_callback is still working.
>
> Does anyone know why a post_callback would just stop working after upgrading?
It should be working. Current code to call post callbacks didn't change
for quite few years.

ipaserver/plugins/baseldap.py:

class LDAPCreate:
   
   def execute(...)
   
   for callback in self.get_callbacks('post'):
   entry_attrs.dn = callback(
   self, ldap, entry_attrs.dn, entry_attrs, *keys, **options)


Looking at get_callbacks(), it is implemented this way, the code was
moved around in 2016 but it is basically the same as it was before:

   @classmethod
   def get_callbacks(cls, callback_type):
   """Yield callbacks of the given type"""
   # Use one shared callback registry, keyed on class, to avoid problems
   # with missing attributes being looked up in superclasses
   callbacks = _callback_registry.get(callback_type, {}).get(cls, [None])
   for callback in callbacks:
   if callback is None:
   try:
   yield getattr(cls, '%s_callback' % callback_type)
   except AttributeError:
   pass
   else:
   yield callback

where callback type is either 'pre', 'post', or 'exc', so if
pre-callbacks are working, then post-callbacks should work as well
because the are called in the same way.

You can enable server-side debugging (add 'debug=True') to
/etc/ipa/default.conf or to /etc/ipa/server.conf (the latter would
affect only server, the former would affect CLI too).

I just tested this with RHEL 7.4 with the plugin below:

--
from ipaserver.plugins import user
import logging

def my_post_callback(self, ldap, dn, entry_attrs, *keys, **options):
   logging.error("my_post_callback called with dn={}".format(dn))
   return dn

user.user_add.register_post_callback(my_post_callback)
---

[root@rh72s ~]# ipa user-add my_foo_bar3
First name: Test
Last name: Bar3

Added user "my_foo_bar3"

 User login: my_foo_bar3
 First name: Test
 Last name: Bar3
 Full name: Test Bar3
 Display name: Test Bar3
 Initials: TB
 Home directory: /home/my_foo_bar3
 GECOS: Test Bar3
 Login shell: /bin/sh
 Principal name: my_foo_b...@t.ipa.cool
 Principal alias: my_foo_b...@t.ipa.cool
 Email address: my_foo_b...@t.ipa.cool
 UID: 12916
 GID: 12916
 Password: False
 Member of groups: ipausers
 Kerberos keys available: False

Here is what I've got in the httpd's error_log:

ERROR:root:my_post_callback called with 
dn=uid=my_foo_bar3,cn=users,cn=accounts,dc=t,dc=ipa,dc=cool
[Fri Jan 12 20:49:16.013460 2018] [:error] [pid 7404] ipa: INFO: 
[jsonserver_session] ad...@t.ipa.cool: user_add/1(u'my_foo_bar3', 
givenname=u'Test', sn=u'Bar3', version=u'2.228'): SUCCESS

--
/ Alexander Bokovoy

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org