ACME certs fail to renew
by Antoine Gatineau
Hello,
I have a strange issue regarding acme service.
My acme certificates fail to renew. `ipa-acme-manage status`fails with
error:
Failed to authenticate to CA REST API
The ipa-acme-manage command failed.
certbot client fails with error "Failed to renew certificate
office.empire.lan with error: <Response [404]>"
$ ipa cert-show 49
Issuing CA: ipa
Certificate: "The certificate content"
Subject: CN=office.empire.lan
Subject DNS name: office.empire.lan
Issuer: CN=Certificate Authority,O=EMPIRE.LAN
Not Before: Sun Dec 24 14:05:50 2023 UTC
Not After: Sat Mar 23 14:05:50 2024 UTC
Serial number: 49
Serial number (hex): 0x31
Revoked: False
So last successful renewal was on Dec 24th. Since then I have not really
done anything appart updating.
I don't see any issue in ipaupgrade.log
I am running on centos stream 9
idm-jss.x86_64 5.5.0-1.el9
idm-jss-tomcat.x86_64 5.5.0-1.el9
idm-ldapjdk.noarch 5.5.0-1.el9
idm-pki-acme.noarch 11.5.0-1.el9
idm-pki-base.noarch 11.5.0-1.el9
idm-pki-ca.noarch 11.5.0-1.el9
idm-pki-java.noarch 11.5.0-1.el9
idm-pki-kra.noarch 11.5.0-1.el9
idm-pki-server.noarch 11.5.0-1.el9
idm-pki-tools.x86_64 11.5.0-1.el9
ipa-client.x86_64 4.11.0-9.el9
ipa-client-common.noarch 4.11.0-9.el9
ipa-common.noarch 4.11.0-9.el9
ipa-healthcheck.noarch 0.16-2.el9
ipa-healthcheck-core.noarch 0.16-2.el9
ipa-selinux.noarch 4.11.0-9.el9
ipa-server.x86_64 4.11.0-9.el9
ipa-server-common.noarch 4.11.0-9.el9
ipa-server-dns.noarch 4.11.0-9.el9
I have followed closely the update on centos stream 9
Running `ipa-acme-manage status` with the -d switch gives me
ipapython.ipaldap: DEBUG: retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-EMPIRE-LAN.socket
conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f123c07e2e0>
ipaserver.masters: DEBUG: Discovery: available servers for service 'CA'
are ipa-server-01.empire.lan, ipa-server-02.empire.lan
ipaserver.masters: DEBUG: Discovery: using ipa-server-01.empire.lan for
'CA' service
ipapython.dogtag: DEBUG: request POST
https://ipa-server-01.empire.lan:8443/acme/login
ipapython.dogtag: DEBUG: request body ''
ipapython.dogtag: DEBUG: response status 404
ipapython.dogtag: DEBUG: response headers Content-Type:
text/html;charset=utf-8
Content-Language: en
Content-Length: 765
Date: Thu, 28 Mar 2024 10:00:59 GMT
ipapython.dogtag: DEBUG: response body (decoded): b'<!doctype html><html
lang="en"><head><title>HTTP Status 404 \xe2\x80\x93 Not
Found</title><style type="text/css">body
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP
Status 404 \xe2\x80\x93 Not Found</h1><hr class="line" /><p><b>Type</b>
Status Report</p><p><b>Message</b> The requested resource
[/acme/login] is not available</p><p><b>Description</b> The
origin server did not find a current representation for the target
resource or is not willing to disclose that one exists.</p><hr
class="line" /><h3>Apache Tomcat/9.0.62</h3></body></html>'
ipapython.admintool: DEBUG: File
"/usr/lib/python3.9/site-packages/ipapython/admintool.py", line 180, in
execute
return_value = self.run()
File
"/usr/lib/python3.9/site-packages/ipaserver/install/ipa_acme_manage.py",
line 403, in run
with state as ca_api:
File
"/usr/lib/python3.9/site-packages/ipaserver/install/ipa_acme_manage.py",
line 103, in __enter__
raise errors.RemoteRetrieveError(
ipapython.admintool: DEBUG: The ipa-acme-manage command failed,
exception: RemoteRetrieveError: Failed to authenticate to CA REST API
ipapython.admintool: ERROR: Failed to authenticate to CA REST API
ipapython.admintool: ERROR: The ipa-acme-manage command failed.
So it looks like the acme subsystem is not started. But logs for the
acme subsystem in /var/log/pki/pki-tomcat/acme/debug.2024-03-28.log
don't show any issue. (see attached log)
How can I go further in troubleshooting/fixing this issue?
Thanks
2 months
One freeipa replica install fails, while other is going through
by D S
Hello,
I am trying to install 3 replicas agains the same master. Two out of 3 installs succeed, while the other one fails with
On replica:
Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
Check RPC connection to remote master
Execute check on remote master
ERROR: Remote master check failed with following error message(s):
an internal error has occurred
2024-03-28T09:09:28Z DEBUG Starting external process
2024-03-28T09:09:28Z DEBUG args=['/usr/sbin/ipa-client-install', '--unattended', '--uninstall']
2024-03-28T09:09:31Z DEBUG Process finished, return code=0
2024-03-28T09:09:31Z DEBUG File "/usr/lib/python3.6/site-packages/ipapython/admintool.py", line 180, in execute
return_value = self.run()
File "/usr/lib/python3.6/site-packages/ipapython/install/cli.py", line 344, in run
return cfgr.run()
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 358, in run
self.validate()
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 368, in validate
for _nothing in self._validator():
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, in __runner
exc_handler(exc_info)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 455, in _handle_validate_exception
self._handle_exception(exc_info)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, in __runner
step()
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, in <lambda>
step = lambda: next(self.__gen)
File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from
six.reraise(*exc_info)
File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from
value = gen.send(prev_value)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 633, in _configure
next(validator)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 431, in __runner
exc_handler(exc_info)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 455, in _handle_validate_exception
self._handle_exception(exc_info)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 518, in _handle_exception
self.__parent._handle_exception(exc_info)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 515, in _handle_exception
super(ComponentBase, self)._handle_exception(exc_info)
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 450, in _handle_exception
six.reraise(*exc_info)
File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 421, in __runner
step()
File "/usr/lib/python3.6/site-packages/ipapython/install/core.py", line 418, in <lambda>
step = lambda: next(self.__gen)
File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 81, in run_generator_with_yield_from
six.reraise(*exc_info)
File "/usr/lib/python3.6/site-packages/six.py", line 693, in reraise
raise value
File "/usr/lib/python3.6/site-packages/ipapython/install/util.py", line 59, in run_generator_with_yield_from
value = gen.send(prev_value)
File "/usr/lib/python3.6/site-packages/ipapython/install/common.py", line 65, in _install
for unused in self._installer(self.parent):
File "/usr/lib/python3.6/site-packages/ipaserver/install/server/__init__.py", line 597, in main
replica_promote_check(self)
File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 401, in decorated
func(installer)
File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 423, in decorated
func(installer)
File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 1196, in promote_check
ca_cert_file=cafile)
File "/usr/lib/python3.6/site-packages/ipaserver/install/replication.py", line 129, in replica_conn_check
"Connection check failed!"
2024-03-28T09:09:31Z DEBUG The ipa-replica-install command failed, exception: ScriptError: Connection check failed!
See /var/log/ipareplica-conncheck.log for more information.
If the check results are not valid it can be skipped with --skip-conncheck parameter.
2024-03-28T09:09:31Z ERROR Connection check failed!
See /var/log/ipareplica-conncheck.log for more information.
If the check results are not valid it can be skipped with --skip-conncheck parameter.
2024-03-28T09:09:31Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
On master:
[Thu Mar 28 09:09:27.891561 2024] [:error] [pid 22098] ipa: ERROR: non-public: DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[Thu Mar 28 09:09:27.891666 2024] [:error] [pid 22098] Traceback (most recent call last):
[Thu Mar 28 09:09:27.891683 2024] [:error] [pid 22098] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 369, in wsgi_execute
[Thu Mar 28 09:09:27.891694 2024] [:error] [pid 22098] result = command(*args, **options)
[Thu Mar 28 09:09:27.891705 2024] [:error] [pid 22098] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 450, in __call__
[Thu Mar 28 09:09:27.891717 2024] [:error] [pid 22098] return self.__do_call(*args, **options)
[Thu Mar 28 09:09:27.891727 2024] [:error] [pid 22098] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 478, in __do_call
[Thu Mar 28 09:09:27.891737 2024] [:error] [pid 22098] ret = self.run(*args, **options)
[Thu Mar 28 09:09:27.891748 2024] [:error] [pid 22098] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 800, in run
[Thu Mar 28 09:09:27.891928 2024] [:error] [pid 22098] return self.execute(*args, **options)
[Thu Mar 28 09:09:27.891951 2024] [:error] [pid 22098] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/server.py", line 933, in execute
[Thu Mar 28 09:09:27.891962 2024] [:error] [pid 22098] ret, stdout, _stderr = server.conncheck(keys[-1])
[Thu Mar 28 09:09:27.891973 2024] [:error] [pid 22098] File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 70, in __call__
[Thu Mar 28 09:09:27.891983 2024] [:error] [pid 22098] return self._proxy_method(*args, **keywords)
[Thu Mar 28 09:09:27.891994 2024] [:error] [pid 22098] File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 145, in __call__
[Thu Mar 28 09:09:27.892005 2024] [:error] [pid 22098] **keywords)
[Thu Mar 28 09:09:27.892016 2024] [:error] [pid 22098] File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
[Thu Mar 28 09:09:27.892026 2024] [:error] [pid 22098] message, timeout)
[Thu Mar 28 09:09:27.892037 2024] [:error] [pid 22098] DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[Thu Mar 28 09:09:27.892955 2024] [:error] [pid 22098] ipa: INFO: [jsonserver_kerb] local_admin(a)EXAMPLE.COM: server_conncheck(u'ipamaster01.example.com', u'ipa-replica03.example.com', version=u'2.162'): InternalError
[Thu Mar 28 09:09:30.121019 2024] [:error] [pid 20997] ipa: INFO: [jsonserver_kerb] host/ipa-replica03.example.com(a)EXAMPLE.COM: host_disable(u'ipa-replica03.example.com'): SUCCESS
2 months
problem with configuration replication in ipa server
by Richard Halley
Hi everyone, I'm configuring the freeipa replication as follows:
1) ipa-client-install --domain=pippo.internal --realm=PIPPO.INTERNAL -N
2) I add the client to the ipaserver host group
3) ipa-replica-install -N --setup-dns --forwarder 8.8.8.8 --forwarder 8.8.4.4 --forwarder 1.1.1.1 --setup-ca
After running ipa-replica-install I get the following error:
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipapython.admintool: ERROR A replication agreement for this host already exists. It needs to be removed.
Run this command:
%% ipa-replica-manage del pluto.pippo.internal --force
ipapython.admintool: ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
I would like to point out that I have attempted the configuration several times without success.
Before proceeding with the uninstall commands of the client and the replica on the replica server, I delete the replica on the server (which fails because it does not find any replica) and then proceed with deleting the client.
In the replication log file I have the following error:
2024-03-28T12:05:10Z DEBUG The ipa-replica-install command failed, exception: ScriptError: A replication agreement for this host already exists. It needs to be removed.
Run this command:
%% ipa-replica-manage del pluto.pippo.internal --force
2024-03-28T12:05:10Z ERROR A replication agreement for this host already exists. It needs to be removed.
Run this command:
%% ipa-replica-manage del pluto.pippo.internal --force
2024-03-28T12:05:10Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
I can't understand where the problem is.
Could it be something dirty in LDAP?
Thank you very much
2 months
Revoked certificates not appearing in CRL
by Sam Morris
It looks like my CRL renewal master (RHEL 8) is not producing the CRL
correctly.
I've got two certificates that were requested by certmonger running on
an ipa client. I'm pretty sure I revoked them as an admin logged into a
second ipa client.
Status of all replication agreements on all ipa servers is green.
The CRL renewal master knows the certificates were issued & revoked:
$ ipa cert-find --validnotbefore-from=2024-03-14 --status=REVOKED
----------------------
2 certificates matched
----------------------
Issuing CA: ipa
Subject: CN=myhost.example.com,O=EXAMPLE.COM
Issuer: CN=Certificate Authority,O=EXAMPLE.COM
Not Before: Thu Mar 14 20:29:31 2024 UTC
Not After: Wed Jul 17 20:29:31 2024 UTC
Serial number: 1342111806
Serial number (hex): 0x4FFF003E
Status: REVOKED
Revoked: True
Issuing CA: ipa
Subject: CN=myhost.example.com,O=EXAMPLE.COM
Issuer: CN=Certificate Authority,O=EXAMPLE.COM
Not Before: Thu Mar 14 20:35:03 2024 UTC
Not After: Wed Jul 17 20:35:03 2024 UTC
Serial number: 1342111807
Serial number (hex): 0x4FFF003F
Status: REVOKED
Revoked: True
----------------------------
Number of entries returned 2
----------------------------
* Both certificates are revoked
* Both certificates have 'not after' dates in the future.
But looking at the current CRL:
$ openssl crl -in /var/lib/ipa/pki-ca/publish/MasterCRL.bin -inform der -noout -text
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O = EXAMPLE.COM, CN = Certificate Authority
Last Update: Mar 23 13:18:45 2024 GMT
Next Update: Mar 23 17:00:00 2024 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:1B:89:B8:D6:6F:4D:41:C1:BD:47:A3:9B:21:36:8C:71:10:59:8C:A6
X509v3 CRL Number:
10526
Revoked Certificates:
Serial Number: 2FFE002B
Revocation Date: May 19 17:01:12 2022 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Signature Algorithm: sha256WithRSAEncryption
0f:2f:59:9b:9c:1c:ac:fd:6a:e5:d7:87:94:97:e3:a8:cf:07:
fe:86:8b:4e:a6:37:dc:76:c1:ef:f3:69:9e:e3:5c:8a:dd:12:
cb:fa:4a:97:21:ae:fa:ee:91:bb:37:9e:cb:bb:49:10:58:95:
bd:24:98:df:a1:45:90:b3:f1:51:af:2b:c9:cb:c3:89:23:a8:
f5:8d:3f:d4:4e:4b:a6:ef:d6:96:94:36:da:a1:0c:ab:32:27:
85:24:0d:9c:52:17:17:4d:ae:3a:83:59:39:a9:08:33:7d:f4:
05:74:e3:7d:1e:df:8e:f8:4c:c0:fd:7f:8b:a2:b4:0a:a2:fc:
57:9b:00:c2:29:9e:74:0f:c2:4a:0e:5c:e6:f0:1e:ff:71:a9:
f9:cb:a1:6f:b4:48:16:59:42:78:2a:38:1d:14:b7:d3:58:cb:
21:ad:61:bb:c9:20:e6:c2:39:97:bf:a6:f8:fe:26:32:51:eb:
67:b4:0c:b9:ea:96:ea:b0:66:cf:7c:73:74:69:fc:08:d9:a7:
13:23:34:3e:a6:f1:b3:0d:0f:54:46:22:71:6c:16:81:a8:97:
79:c5:a0:20:03:5d:51:d7:fb:25:33:3b:7a:55:59:dd:a6:cb:
3e:00:1d:2a:c7:a3:7a:8b:3b:1f:d9:36:23:c5:c3:f4:ff:14:
86:0b:61:fc
* The CRL was just generated a few minutes ago
* The two revoked certificates are not present
* The certificate that is present in the list expired in July 2022,
according to 'ipa cert-show 0x2FFE002B'
To force CRL generation I'm running:
$ curl https://$HOSTNAME:8443/ca/agent/ca/updateCRL --cert /var/lib/ipa/ra-agent.pem --key /var/lib/ipa/ra-agent.key
Nothing suspicious shows up in Dogtag's logs:
==> /var/log/pki/pki-tomcat/ca/debug.2024-03-23.log <==
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: Getting SSL client certificate.
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: CertUserDBAuthentication: UID ipara authenticated.
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: UGSubsystem: retrieving user uid=ipara,ou=People,o=ipaca
2024-03-23 13:42:12 [https-jsse-nio-8443-exec-6] INFO: AAclAuthz: Granting update permission for certServer.ca.crl
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CRLIssuingPoint: Updating MasterCRL
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CASigningUnit: Getting algorithm context for SHA256withRSA RSASignatureWithSHA256Digest
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CASigningUnit: Signing Certificate
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CRLReposiotry: Updating CRL issuing point record
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: LDAPSession: Modifying LDAP entry cn=MasterCRL,ou=crlIssuingPoints,ou=ca,o=ipaca
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: Getting crl publishing rules
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapXCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCaCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: FileCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: true
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: type: crl
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: predicate: null
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapUserCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing CRL 10529 to MasterCRL
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: Getting crl publishing rules
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapXCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCaCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: FileCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: true
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: type: crl
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: predicate: null
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapUserCertRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: - name: LdapCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: PublisherProcessor: enabled: false
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing rules:
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: - rule: FileCrlRule
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: mapper: NoMap
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Publishing to CN=Certificate Authority,O=EXAMPLE.COM
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: - publisher: FileBaseCRLPublisher
2024-03-23 13:42:12 [CRLIssuingPoint-MasterCRL] INFO: CAPublisherProcessor: Published CRL
==> /var/log/pki/pki-tomcat/ca/signedAudit/ca_audit <==
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_ESTABLISH][ClientIP=--][ServerIP=--][SubjectID=CN=IPA RA,O=EXAMPLE.COM][Outcome=Success] access session establish success
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=AUTH][SubjectID=ipara][Outcome=Success][AuthMgr=certUserDBAuthMgr] authentication success
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=AUTHZ][SubjectID=ipara][Outcome=Success][aclResource=certServer.ca.crl][Op=update] authorization success
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ROLE_ASSUME][SubjectID=ipara][Outcome=Success][Role=Certificate Manager Agents, Registration Manager Agents, Security Domain Administrators, Enterprise ACME Administrators] assume privileged role
0.https-jsse-nio-8443-exec-6 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=SCHEDULE_CRL_GENERATION][SubjectID=ipara][Outcome=Success] schedule for CRL generation
0.https-jsse-nio-8443-exec-7 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=--][ServerIP=--][SubjectID=--][Outcome=Success][Info=serverAlertReceived: CLOSE_NOTIFY] access session terminated
0.https-jsse-nio-8443-exec-7 - [23/Mar/2024:13:42:12 UTC] [14] [6] [AuditEvent=ACCESS_SESSION_TERMINATED][ClientIP=--][ServerIP=--][SubjectID=--][Outcome=Success][Info=serverAlertSent: CLOSE_NOTIFY] access session terminated
This may be related to <https://pagure.io/freeipa/issue/9505>. I've not
had the chance to test revocation on an ipa server yet.
Any other debugging I can do just let me know.
--
Sam Morris <https://robots.org.uk/>
CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
2 months, 1 week
upgrade idm servers rhel 7 to 8 problems
by Natxo Asenjo
hi,
at work we are having *interesting* problems with our migration from idm
servers running rhel 7 to new rhel 8 idm servers.
We have a AD -> idm trust in place, this is working properly.
AD is domain.local
IDM is idm.domain.local
We add replicas to the set, and this runs properly. No replication errors.
Basically the problem is we cannot log in to newly joined systems running
rhel 8 as trusted users from AD.
We have a new rhel 8 idm server which has also the trust agent and trust
controller role installed.
We want to login as a trusted AD user to a rhel 8 host which has this new
rhel 8 idm server as its ipa host, we have forced it using this sssd.conf:
[domain/idm.domain.local]
id_provider = ipa
ipa_server = ds.idm.domain.local
ipa_domain = idm.domain.local
ipa_hostname = host.idm.domain.local
auth_provider = ipa
chpass_provider = ipa
access_provider = ipa
cache_credentials = True
ldap_tls_cacert = /etc/ipa/ca.crt
dyndns_update = True
dyndns_iface = ens192
krb5_store_password_if_offline = True
[sssd]
services = nss, pam, ssh, sudo
domains = idm.domain.local
full_name_format = %1$s
debug = 9
[nss]
homedir_substring = /home
override_homedir = /home/%u
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
[session_recording]
We also modified krb5.conf on the client to find the IDM realm only on the
rhel 8 idm server, not the rhel 7. So we disabled srv dns autodiscovery for
the IDM.DOMAIN.LOCAL realm:
# cat /etc/krb5.conf
#File modified by ipa-client-install
includedir /etc/krb5.conf.d/
[libdefaults]
default_realm = IDM.DOMAIN.LOCAL
dns_lookup_realm = true
rdns = false
dns_canonicalize_hostname = false
dns_lookup_kdc = true
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
IDM.DOMAIN.LOCAL = {
kdc = ds.idm.domain.local:88
master_kdc = ds.idm.domain.local:88
admin_server = ds.idm.domain.local:749
kpasswd_server = ds.idm.domain.local:464
default_domain = idm.domain.local
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
[domain_realm]
.idm.domain.local = IDM.DOMAIN.LOCAL
idm.domain.local = IDM.DOMAIN.LOCAL
host.idm.domain.local = IDM.DOMAIN.LOCAL
On the rhel 8 client, I can kinit with the host keytab, this work, I get a
ticket with the host principal.
I can also kinit using a trusted AD user, this works, I get a ticket of the
AD domain.
But as soon as I try logging in from ssh, it does not work. It does not
recognize the user.
Running id trusteduser@ad does not wok either (no such user)
I have run out of ideas, to be honest. I do not know how to troubleshoot
this anymore. The rhel8 idm server finds the users, I can log in there
without any problem too thanks to the rbac rules, but this rhel8 client
simpley will not see the users.
Any ideas?
Thanks in advance.
--
Groeten,
natxo
2 months, 1 week
cannot login into account after migration to 4.10.x
by Piotr Miedzik
Hi
I have problem with some users after updating freeipa server.
As of freeipa 4.10 I'm not able to login if user was created with uid specified (ipa user-add testx --uid=1001 --first=p --last=m --password)
It also doesn't work for accounts created with previous freeipa versions.
steps to reproduce:
1) install
podman run --rm -p 10.58.0.45:53:53/udp -p 10.58.0.45:53:53 -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp --name ipa01 -ti -h ipa01.dev.example.com -v /srv/ipa01-data/:/data:Z -e freeipa/freeipa-server:fedora-36-4.9.11
2) create account testx with uid
ipa user-add testx --uid=1001 --first=p --last=m --password
3) create account testy without uid
ipa user-add testy --first=p --last=m --password
4) upgrade to newest version
podman run --rm -p 10.58.0.45:53:53/udp -p 10.58.0.45:53:53 -p 80:80 -p 443:443 -p 389:389 -p 636:636 -p 88:88 -p 464:464 -p 88:88/udp -p 464:464/udp -p 123:123/udp --name ipa01 -ti -h ipa01.dev.example.com -v /srv/ipa01-data/:/data:Z -e freeipa/freeipa-server:fedora-38-4.10.3
user testx cannot login, user testy is able to login
2 months, 1 week
admin password changes when joing new replica
by Schweiss, Chip
I'm building out a multisite installation. For unknown reasons, the 'admin'
user password needs to be reset each time I join a new FreeIPA replica.
It seems to happen a minute or two after the ipa-replica-install
completes. Attempts to kinit immediately afterward usually works.
Here's my ipa-replica install command I'm using:
ipa-replica-install -n {domain} -r {realm} -d \
--server={existing_ipa_server} \
--setup-adtrust --add-agents --mkhomedir \
--ntp-pool={my_ntp_pool} \
-p $otp
How do I track down the cause of this?
-Chip
2 months, 1 week
Re: Using ipa-ca-install on a replica
by Ian Kumlien
On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien <ian.kumlien(a)gmail.com> wrote:
>
> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud <flo(a)redhat.com> wrote:
> >
> > Hi,
> >
> > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien <ian.kumlien(a)gmail.com> wrote:
> >>
> >> On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien <ian.kumlien(a)gmail.com> wrote:
> >> >
> >> > So... this one's new:
> >> >
> >> > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> >> > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> >> > Unspecified GSS failure. Minor code may provide more information
> >> > (Credential cache is empty)
> >
> >
> > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
>
> Ah, ok, i did do kdestroy -A but only on the new machine...
>
> A new issue that appeared, no user from the old machines can
> authenticate at all - still looking in to why it doesn't work
Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
Any clues?
> > flo
> >>
> >> > ---
> >> >
> >> > Just haven't seen it before... and it seems like the replica can't
> >> > install, unlike the two that worked before...
> >>
> >> And all of the sudden it just works again... weird...
> >>
2 months, 1 week
ipa-getkeytab fails
by Dmitry Krasov
Hello.
Centos 9 client
Trying get new keytab from ipa (ubuntu), by this command (after kinit):
ipa-getkeytab -s ipa.dom.loc -p host/clienthost.l3874.ru -k /etc/krb5.keytab
Failed to get key table file
"update-crypto-policies --set DEFAULT:AD-SUPPORT-LEGACY" doesn't help
On ubuntu clients " ipa-getkeytab --permitted-enctypes" shows:
AES-256 CTS mode with 96-bit SHA-1 HMAC
AES-128 CTS mode with 96-bit SHA-1 HMAC
AES-256 CTS mode with 192-bit SHA-384 HMAC
AES-128 CTS mode with 128-bit SHA-256 HMAC
Triple DES cbc mode with HMAC/sha1
ArcFour with HMAC/md5
Camellia-128 CTS mode with CMAC
Camellia-256 CTS mode with CMAC
But on Centos 9 are AES types only.
How can I add other 4 types?
2 months, 1 week
Re: Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
by Rob Crittenden
Kroon PC, Peter via FreeIPA-users wrote:
> Thanks for the super fast reply! I'll do my best to reply in-line, but I'm bound to outlook, which doesn't like it too much.
>
>>> Hi all!
>>>
>>> I'm working on updating my freeipa server from rocky 8 to 9. I'm playing around with a virtual machines as playground server and client, since I'd rather not break my everything right away. As part of this, I first installed ipa-server version 4.10.2-8.el9_3 on the server. Then I did an ipa-restore with a backup from my production ipa server (rocky 8, 4.9.12-11.module+el8.9.0+1652+4ee71f6a), followed by an ipa-server-upgrade. All is well so far (I think).
>
>> I don't know how you achieved this. ipa-restore attempts to prevent
>> using restore as a backdoor upgrade mechanism.
>
> It didn't complain /too/ much honestly. It saw the version mismatch between the backup and the installed server, asked for a "yes", and then happily went on its way. Is there a better way to achieve what I want/need?
Create a replica and disconnect it from the topology to have a sandbox.
>>> The client is running Debian bookworm with backports, where the latest ipa-client version is 4.9.11-1. Then, I went with the usual ipa-client-install --no-ntp, which fails with "Joining realm failed: Failed to parse result: PrincipalName not found." after retrieving the CA cert.
>>> The logs don't tell me much more, but the --debug flag does. It negotiates a JSON-RPC response, in which it says '{... "principal": "admin(a)EXAMPLE.COM", ...}'. I note that principal != PrincipalName. Also note, that on the server, the host /is/ added.
>>>
>>> So I guess my question is: how much version skew between server and client is supported?
>
>> Plenty. There isn't much to client enrollment and the API hasn't changed
>> significantly in a long time.
>
> Ok. Is there any other place I can look for what's going wrong?
The server httpd error log should have something about the request as
well as the client install log.
To get more details on the server side you can create
/etc/ipa/server.conf with the contents:
[global]
debug = True
Then restart httpd. Warning, it can be very verbose so I wouldn't leave
it like that for long in production.
rob
2 months, 1 week