FreeIPA PKI Certs wont renew "Adjustment limit exceeded"
by T A
On FreeIPA version 4.6.8-5 realized that pki-tomcatd wouldnt start
ipactl status
pki-tomcatd Service: STOPPED
Ran 'getcert list' and found the 'pki-tomcat' cert was expired
Rolled back the system clock to before the cert expired, now starts up
ipactl status
pki-tomcatd Service: STARTED
Tried to renew with 'ipa-getcert resubmit -i "123456"' but it shows "status: CA_UNREACHABLE"
'ipa-cert fix' didnt work either
Checked logs again 'journalctl -t certmonger' and found 'ns-slapd' was giving out this error when it tried to renew 'csngen_adjust_local_time - Adjustment limit exceeded: value - 435060 limit - 86400'
Any way to change the adjustment limit or force this cert to renew anyway?
2 days, 2 hours
Installing FreeIPA server + replica using Ansible Role FreeIPA
by Finn Fysj
The installation of IPA server and replica does not produce desired result.
Even though the mkhomedir is set to true the feature is not enabled in the authselect. Also the replica server does not replicate SUDO and HBAC rules from the IPA master.
Is the only solution to re-install the whole IPA server/replicas stuff? Kinda stupid.
Example of the IPA server role:
- role: freeipa.ansible_freeipa.ipaserver
vars:
ipaserver: "{{ ansible_hostname }}.example"
ipaserver_hostname: "{{ ansible_hostname }}.example"
ipaadmin_password: "test123"
ipadm_password: "test321"
ipaserver_domain: "example.com"
ipaserver_realm: "EXAMPLE.COM"
ipaserver_no_host_dns: true
ipaserver_mem_check: true
ipaserver_install_packages: true
ipaserver_setup_dns: false
ipaserver_no_pkinit: true
ipaserver_no_hbac_allow: true
ipaserver_no_ui_redirect: false
ipaclient_no_ntp: true
ipaclient_mkhomedir: true
ipaclient_no_sudo: false
4 days, 8 hours
kinit: KDC can't fulfill requested option while renewing credentials - which approach?
by Pieter Baele
I tried various approached to get Renewable tickets :
modifying the kdc
modifying krb5.conf
using kadmin.local on every replica to modify the principal; which is not
working - as designed (?)- in IPA
What should I do to get a ticket with the correct R flag from IPA ?
I don't think this is SSSD related (the service needing the renewable
ticket this way is Apache Storm)
Thanks a lot!
4 days, 22 hours
AIX - IPA group membership
by Ronald Wimmer
I can and use IPA users on an AIX client. As well as groups. But somehow
group membership does not seem to be configured correctly...
# id y179768
uid=1246660005(y179768) gid=1246660005(y179768)
# lsgroup -R LDAP ipa-aix-g
ipa-aix-g id=1246690508 users= registry=LDAP
Anyone has a hint what could be misconfigured?
1 week, 6 days
certgmonger not able to renew a certificate: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)).
by Sam Morris
Hi folks, I've got a machine where certmonger is unable to renew a
certificate request:
# getcert list -i 20220519165212
Number of certificates and requests being tracked: 2.
Request ID '20220519165212':
status: MONITORING
ca-error: Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)).
stuck: no
key pair storage: type=FILE,location='/etc/cockpit/ws-certs.d/51-xoanon.key'
certificate: type=FILE,location='/etc/cockpit/ws-certs.d/51-xoanon.crt'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
subject: CN=xoanon.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-06-21 07:49:49 UTC
expires: 2023-09-19 07:49:49 UTC
dns: xoanon.ipa.example.com
principal name: host/xoanon.ipa.example.com(a)IPA.EXAMPLE.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
I'm manually attempting to renew the certificate with:
[root@xoanon ~]# getcert resubmit -w -v -i 20220519165212
Resubmitting "20220519165212" to "IPA".
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State MONITORING, stuck: no.
On the server side, I'm unable to find any errors being logged anywhere.
Even after I set 'debug = true' in /etc/ipa/default.conf & restarted
httpd.service, the only log messages are:
==> /var/log/httpd/error_log <==
[Wed Aug 23 10:59:50.765980 2023] [wsgi:error] [pid 124570:tid 140295030843136] [remote 192.168.88.3:52224] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Wed Aug 23 10:59:50.766232 2023] [wsgi:error] [pid 124570:tid 140295030843136] [remote 192.168.88.3:52224] ipa: DEBUG: WSGI jsonserver.__call__:
[Wed Aug 23 10:59:50.766352 2023] [wsgi:error] [pid 124570:tid 140295030843136] [remote 192.168.88.3:52224] ipa: DEBUG: KerberosWSGIExecutioner.__call__:
==> /var/log/httpd/access_log <==
192.168.88.3 - host/xoanon.ipa.example.com(a)IPA.EXAMPLE.COM [23/Aug/2023:10:59:50 +0000] "POST /ipa/json HTTP/1.1" 200 526
... which show that the API call was successful. On the other hand,
according to 'ipa cert-find --subject=xoanon.ipa.example.com', no
certificates have been issued.
It looks like the API isn't calling out to PKI/Dogtag, since nothing is
logged to /var/log/pki/pki-tomcat/localhost_access_log.*.txt or
/var/log/pki/pki-tomcat/ca/debug.*.log.
I also looked for AVC denials and didn't see anything in /var/log/audit.
So, back to the client. certmonger logs the following:
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_REQ_SUBJECT" to "CN=xoanon.ipa.example.com" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_REQ_HOSTNAME" to "xoanon.ipa.example.com" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_REQ_PRINCIPAL" to "host/xoanon.ipa.example.com(a)IPA.EXAMPLE.COM" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_OPERATION" to "SUBMIT" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_CSR" to "-----BEGIN CERTIFICATE REQUEST-----
MIIEpzCCAw8CAQAwIzEhMB8GA1UEAxMYeG9hbm9uLmlwYS5yb2JvdHMub3JnLnVr
[...]
4d6BlUMScGAgCAxfxEb1eXymTxVm/Do/liHaOqnHGVIr+1OjZNftrUODFQ==
-----END CERTIFICATE REQUEST-----
" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_SPKAC" to "[...]" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_SPKI" to "[...]" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_LOCAL_CA_DIR" to "/var/lib/certmonger/local" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_KEY_TYPE" to "RSA" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_CA_NICKNAME" to "IPA" for child.
2023-08-23 11:15:50 [836073] Setting "CERTMONGER_CERTIFICATE" to "-----BEGIN CERTIFICATE-----
MIIFajCCBFKgAwIBAgIET/8AJDANBgkqhkiG9w0BAQsFADA8MRowGAYDVQQKDBFJ
[...]
dF6L+2tIIpjYylCxKQISWaexKkv1jVQaIPB1foIKyLGaf9YtyaIwyoM9G80UaQ==
-----END CERTIFICATE-----
" for child.
2023-08-23 11:15:50 [836073] Redirecting stdin to /dev/null, leaving stdout and stderr open for child "/usr/libexec/certmonger/ipa-submit".
2023-08-23 11:15:50 [836073] Running enrollment helper "/usr/libexec/certmonger/ipa-submit".
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
Submitting request to "https://ipa5.ipa.example.com/ipa/json".
JSON-RPC error: 2100: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
2023-08-23 11:15:50 [834693] Certificate submission still ongoing.
2023-08-23 11:15:50 [834693] Certificate submission attempt complete.
2023-08-23 11:15:50 [834693] Child status = 2.
2023-08-23 11:15:50 [834693] Child output:
"Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)).
"
2023-08-23 11:15:50 [834693] Server at https://ipa5.ipa.example.com/ipa/json denied our request, giving up: 2100 (Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)).
2023-08-23 11:15:50 [834693] Certificate not (yet?) issued.
2023-08-23 11:15:50 [834693] Wrote to /var/lib/certmonger/requests/20220519165212
I found that I could add 'OPTS=-d9' to /etc/sysconfig/certmonger &
restart certmonger.service, which does cause it to log more, but it
doesn't give any further insight into the messages exchanged with the
server.
Does anyone know where I can look next?
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
2 weeks, 3 days
Free IPA DNS Issues
by Pradeep KNS
Hello Team,
While setting up Freeipa in my Linux infrastructure.I noticed a strange
warning. I would like to clarify before rolling into production.
*DNS zone alpha-grep.com <http://alpha-grep.com>. already exists in DNS and
is handled by server(s): ['ns2.', 'ns1.'] Please make sure that the domain
is properly delegated to this IPA server.*
Detailed installation log i have updated in this link. Please suggest me
will it be any security flaw in future.Before installing it on production.
https://bpa.st/AMITK
3 weeks, 2 days
ipa certificates expired - can't get the system up and running again
by Andreas Bulling
Dear all,
I am running a FreeIPA instance in our group at the university and, in
the past, replacing SSL certificates for LDAP/HTTPD hasn't been a
problem because I always updated them before they expired (they have to
be renewed every year).
This time, however, the certificates expired before I could renew them.
In addition, university decided to switch to a different CA.
The usual way of renewing certificates didn't work because I got a
"Peer's Certificate has expired." error.
I have read a lot of posts and potential solutions online and, following
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/..."
I managed to manually install the new CA root and intermediate
certificates as well as the LDAP/HTTP certificates into the NSS database
(they show up when using "certutil -d /etc/dirsrv/slapd-DOMAIN/ -L").
Problem: When trying to enroll the new certificates to LDAP storage
using "ipa-server-certinstall" I again/still see the familiar error
"The server certificate in privkey.pem, auth_full.pem is not valid:
certutil: certificate is invalid: Peer's Certificate has expired."
I assume this is because the old certificate (that the LDAP server is
still using) has expired but when setting back system time (which I have
also tried) the new certificate is not valid yet?!
Is the only solution to get a certificate somehow that overlaps both the
old and new validity periods or is there another way, e.g. by forcing
the certificate install by ignoring the expiry?
Thanks a lot in advance!
Andreas
3 weeks, 3 days
anonymous kinit (-n) failed with "PKINIT client could not verify DH reply" (solution)
by Sam Morris
I found that 'kinit -n' was prompting me for the password for
WELLKNOWN/ANONYMOUS(a)IPA.EXAMPLE.COM. This happened on everal, but not
all clients.
After setting the environment variable KRB5_TRACE=/dev/stderr, the
useful parts of the output of 'kinit -n' were:
[826240] 1693432177.150062: PKINIT loading CA certs and CRLs from FILE /var/lib/ipa-client/pki/kdc-ca-bundle.pem
[826240] 1693432177.150063: PKINIT loading CA certs and CRLs from FILE /var/lib/ipa-client/pki/ca-bundle.pem
[826240] 1693432177.150064: PKINIT client computed kdc-req-body checksum 14/265A6783F1767B3DB744B8ED1FE333185EFFEB7B
[826240] 1693432177.150066: PKINIT client making DH request
[826240] 1693432177.150067: Preauth module pkinit (16) (real) returned: 0/Success
[826240] 1693432177.150068: Produced preauth for next request: PA-FX-COOKIE (133), PA-PK-AS-REQ (16)
[826240] 1693432177.150069: Sending request (1565 bytes) to IPA.EXAMPLE.COM
[826240] 1693432177.150070: Initiating TCP connection to stream 192.0.2.5:88
[826240] 1693432177.150071: Sending TCP request to stream 192.0.2.5:88
[826240] 1693432177.150072: Received answer (1609 bytes) from stream 192.0.2.5:88
[826240] 1693432177.150073: Terminating TCP connection to stream 192.0.2.5:88
[826240] 1693432177.150074: Response was from primary KDC
[826240] 1693432177.150075: Processing preauth types: PA-PK-AS-REP (17), PA-PKINIT-KX (147)
[826240] 1693432177.150076: Preauth module pkinit (147) (info) returned: 0/Success
[826240] 1693432177.150077: PKINIT client could not verify DH reply
[826240] 1693432177.150078: Preauth module pkinit (17) (real) returned: -1765328360/Preauthentication failed
Searching online for "PKINIT client could not verify DH reply" didn't
come up with anything useful so I am writing this message to help anyone
else who might experience a similar problem.
I noticed that all the failing clients were talking to the same IPA
server. And on that server, 'kinit -n' failed with the same message.
As for the underlying cause: it turns out that there was a problem with
the KDC's PKI certificate on the server.
[root@ipa5 ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 12.
Request ID '20221103090547':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: SelfSign
issuer: CN=ipa5.ipa.example.com,O=IPA.EXAMPLE.COM
subject: CN=ipa5.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-07-08 18:12:32 UTC
expires: 2024-07-08 18:12:32 UTC
dns: ipa5.ipa.example.com
principal name: krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
certificate template/profile: KDCs_PKINIT_Certs
profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
Note the CA is "SelfSign", which caused certmonger to generate a
self-signed certificate on 2023-07-08 when it renewed, instead of
contacting the IPA CA.
The fix was to run:
[root@ipa5 ~]# getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -c IPA
Request "20221103090547" modified.
[root@ipa5 ~]# getcert resubmit -w -v -f /var/kerberos/krb5kdc/kdc.crt
Resubmitting "20221103090547" to "IPA".
State GENERATING_CSR, stuck: no.
State SUBMITTING, stuck: no.
State READING_CERT, stuck: no.
State POST_SAVED_CERT, stuck: no.
State MONITORING, stuck: no.
[root@ipa5 ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 12.
Request ID '20221103090547':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
subject: CN=ipa5.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-08-30 21:51:48 UTC
expires: 2023-11-28 21:51:48 UTC
dns: ipa5.ipa.example.com
principal name: krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
certificate template/profile: KDCs_PKINIT_Certs
profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
After this, 'kinit -n' on the server and clients was successful again.
I've no earthly idea how the tracking request was set up with the wrong
CA, but at least this appears to have fixed it.
There are some other differences between the tracking request on this
server and another server (both of which are running fully-updated RHEL
8):
[root@ipa3 ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 12.
Request ID '20210423163239':
status: MONITORING
stuck: no
key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.EXAMPLE.COM
subject: CN=ipa3.ipa.example.com,O=IPA.EXAMPLE.COM
issued: 2023-07-29 16:33:03 UTC
expires: 2023-10-27 16:33:03 UTC
principal name: krbtgt/IPA.EXAMPLE.COM(a)IPA.EXAMPLE.COM
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-pkinit-KPKdc
profile: KDCs_PKINIT_Certs
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
track: yes
auto-renew: yes
On ipa3 the tracking request has no 'dns' line (subsequently, in the
issued certificate there is no dnsName in the subjectAltName extension).
There's also no 'certificate template/profile' line. Neither of these
seem to affect any functionality, but I do wonder where the difference
came from. Perhaps this is a chance in behaviour in freeipa between when
ipa3 and ipa5 were installed?
The tracking request with the wrong CA wasn't picked up by
ipa-healthcheck, I can file an issue about that if it's helpful.
Hopefully someone else could find this info useful.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
3 weeks, 3 days
