Certificate Revoking error in FreeIPA domain
by Albert Stoune
Hello!
I encountered a problem when revoking a certificate: "IPA Error 4035: HTTPRequestError: Request failed with status 500: Non-2xx response from CA REST API: 500."
First of all, I looked at the Apache logs in /var/log/httpd/accsess.log and found next error:
[08/Dec/2023:13:27:39 +0300] "POST /ca/rest/agent/certs/10/revoke HTTP/1.1" 500 6504
Then, in /var/log/httpd/error_log:
ipa: INFO: [jsonserver_session] admin(a)TEST.LOCAL: cert_revoke('10', revocation_reason='0', cacn='ipa', version='2.253'): HTTPRequestError
And finally I found traceback, which looks like bug in DogTag logs in /var/log/pki/pki-tomcat/ca/debug.2023-12-08.log:
2023-12-08 13:27:39 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] INFO: LDAPSession: Retrieving cn=10,ou=certificateRepository, ou=ca,o=ipaca
2023-12-08 13:27:39 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-7] SEVERE: Servlet.service() for servlet [Resteasy] in context with path [/ca] threw exception
org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException: Cannot invoke "String.toLowerCase()" because "<parameter1>" is null
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:78)
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:222)
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:179)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:422)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:764)
at jdk.internal.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.catalina.security.SecurityUtil.lambda$execute$0(SecurityUtil.java:280)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at java.base/javax.security.auth.Subject.doAsPrivileged(Subject.java:584)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:311)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:221)
at org.apache.catalina.core.ApplicationFilterChain.lambda$doFilter$0(ApplicationFilterChain.java:145)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:143)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at jdk.internal.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.apache.catalina.security.SecurityUtil.lambda$execute$0(SecurityUtil.java:280)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at java.base/javax.security.auth.Subject.doAsPrivileged(Subject.java:584)
at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:311)
at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:187)
at org.apache.catalina.core.ApplicationFilterChain.lambda$doFilter$0(ApplicationFilterChain.java:145)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:569)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:143)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:660)
at com.netscape.cms.tomcat.ExternalAuthenticationValve.invoke(ExternalAuthenticationValve.java:83)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.valves.rewrite.RewriteValve.invoke(RewriteValve.java:555)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:687)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360)
at org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:433)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1743)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.NullPointerException: Cannot invoke "String.toLowerCase()" because "<parameter1>" is null
at org.mozilla.jss.netscape.security.x509.RevocationReason.valueOf(RevocationReason.java:91)
at org.dogtagpki.server.ca.rest.CertService.revokeCert(CertService.java:180)
at org.dogtagpki.server.ca.rest.CertService.revokeCert(CertService.java:162)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
... 49 more
It looks like internal mechanisms in DogTag can't parse some arguments from LDAP-response. When I'm check similar request to LDAP with ldapsearch I got response with certificate details. Looks like all correct in LDAP.
Additional info for debug: command "ipactl status" shows like everything is good
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
Also, I can create new certificates, but can't delete already signed. And also I can't delete Services with signed certs, and can't delete Hosts with that Services
FreeIPA version: VERSION: 4.11.0, API_VERSION: 2.253
4 months, 3 weeks
Create IPA user via LDAP
by Ronald Wimmer
In our company we do have an IAM tool for user management. We need to
create IPA users via this particular tool. I am aware of all IPA
commands or API calls to create/modify or delete a user.
As the tool does not support FreeIPA yet they asked if there is a way to
manage users by using LDAP only. Could that work? What about attributes
like ipaNTSecurityIdentifier, ipaUniqueID or uidNumber?
4 months, 3 weeks
Can we go for replica installation without using 80 port instead only using 443 port
by Polavarapu Manideep Sai
Hi Team,
Can we install IPA replica without using 80 port instead only using 443 port? Is it possible ?
If it is possible how can we achieve this ? [using port forwarding ? or any configuration changes?]
If it is not possible, why ?
Regards
Sai
________________________________
DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
4 months, 3 weeks
Integration of lower version of client IPA with higher version of Server IPA
by Polavarapu Manideep Sai
Hi All,
Can ipa client installation/integration possible with below IPA versions ?
IPA Server:
Redhat7.X and IPA 4.6.8
IPA Client:
Redhat6.X and IPA 3.0.0
Regards
Sai
________________________________
DISCLAIMER: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Further, this e-mail may contain viruses and all reasonable precaution to minimize the risk arising there from is taken by OnMobile. OnMobile is not liable for any damage sustained by you as a result of any virus in this e-mail. All applicable virus checks should be carried out by you before opening this e-mail or any attachment thereto.
Thank you - OnMobile Global Limited.
4 months, 3 weeks
Re: possible issue with ipa-backup on RHEL 9.3
by Alexander Bokovoy
On Пят, 22 сне 2023, Charles Hedrick via FreeIPA-users wrote:
>A bit more info. Looking at errors, a normal backup terminates with
>
>[20/Dec/2023:23:01:32.943228301 -0500] - INFO - archive_copyfile - Copying /etc/dirsrv/slapd-CS-RUTGERS-EDU/pwdfile.txt to /var/lib/dirsrv/slapd-\
>CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/pwdfile.txt
>[20/Dec/2023:23:01:32.957342035 -0500] - INFO - archive_copyfile - Copying /etc/dirsrv/slapd-CS-RUTGERS-EDU/certmap.conf to /var/lib/dirsrv/slapd\
>-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/certmap.conf
>[20/Dec/2023:23:01:32.969828971 -0500] - INFO - archive_copyfile - Copying /etc/dirsrv/slapd-CS-RUTGERS-EDU/slapd-collations.conf to /var/lib/dir\
>srv/slapd-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/slapd-collations.conf
>[20/Dec/2023:23:01:32.983763256 -0500] - INFO - task_backup_thread - Backup finished.
>[2
>
>The backup that hung is missing the last line, "Backup finished." ldap
>stopped giving normal responses about a minute later, according to the
>access log.
This looks like a thing internal to 389-ds. If you'd see it reproduced,
make sure to have debuginfo packages for 389-ds and freeipa installed
and then attempt to get a backtrace from 389-ds processes before you'd
kill them.
>________________________________
>From: Charles Hedrick
>Sent: Friday, December 22, 2023 9:56 AM
>To: freeipa-users(a)lists.fedorahosted.org <freeipa-users(a)lists.fedorahosted.org>
>Subject: possible issue with ipa-backup on RHEL 9.3
>
>I just upgraded one of three servers from RHEL 9.2. to 9.3. I have a clone of our three servers, on which all three have been upgraded to 9.3.
>
>All of the servers run a cron job
>
>/sbin/ipa-backup --online --data > /usr/local/scripts/ipa-backup.log 2>&1
>
>The LDAP server hung (needed kill -9) at about the time that job ran, on the production server but not the testing copy. Obviously I can't prove that the backup caused the hang, but it's suspicious. I've commented out the cron job, since the backup isn't actually all the useful. If we have to restore we'd use a snapshot of the VM.
>
>The backup completed successfully on the clone. On the production server it failed. Here is the log:
>
>Preparing backup on krb4.cs.rutgers.edu
>Local roles match globally used roles, proceeding.
>Backing up userRoot in CS-RUTGERS-EDU to LDIF
>Waiting for LDIF to finish
>Backing up CS-RUTGERS-EDU
>Waiting for BAK to finish
>cannot connect to 'ldapi://%2Frun%2Fslapd-CS-RUTGERS-EDU.socket':
>The ipa-backup command failed. See /var/log/ipabackup.log for more information
>
>I'm wondering whether there's a bug that only happens under load.
>
>We're been doing this in production for years with no trouble up to RHEL 9.2.
>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
4 months, 4 weeks
Re: possible issue with ipa-backup on RHEL 9.3
by Charles Hedrick
A bit more info. Looking at errors, a normal backup terminates with
[20/Dec/2023:23:01:32.943228301 -0500] - INFO - archive_copyfile - Copying /etc/dirsrv/slapd-CS-RUTGERS-EDU/pwdfile.txt to /var/lib/dirsrv/slapd-\
CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/pwdfile.txt
[20/Dec/2023:23:01:32.957342035 -0500] - INFO - archive_copyfile - Copying /etc/dirsrv/slapd-CS-RUTGERS-EDU/certmap.conf to /var/lib/dirsrv/slapd\
-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/certmap.conf
[20/Dec/2023:23:01:32.969828971 -0500] - INFO - archive_copyfile - Copying /etc/dirsrv/slapd-CS-RUTGERS-EDU/slapd-collations.conf to /var/lib/dir\
srv/slapd-CS-RUTGERS-EDU/bak/CS-RUTGERS-EDU/config_files/slapd-collations.conf
[20/Dec/2023:23:01:32.983763256 -0500] - INFO - task_backup_thread - Backup finished.
[2
The backup that hung is missing the last line, "Backup finished." ldap stopped giving normal responses about a minute later, according to the access log.
________________________________
From: Charles Hedrick
Sent: Friday, December 22, 2023 9:56 AM
To: freeipa-users(a)lists.fedorahosted.org <freeipa-users(a)lists.fedorahosted.org>
Subject: possible issue with ipa-backup on RHEL 9.3
I just upgraded one of three servers from RHEL 9.2. to 9.3. I have a clone of our three servers, on which all three have been upgraded to 9.3.
All of the servers run a cron job
/sbin/ipa-backup --online --data > /usr/local/scripts/ipa-backup.log 2>&1
The LDAP server hung (needed kill -9) at about the time that job ran, on the production server but not the testing copy. Obviously I can't prove that the backup caused the hang, but it's suspicious. I've commented out the cron job, since the backup isn't actually all the useful. If we have to restore we'd use a snapshot of the VM.
The backup completed successfully on the clone. On the production server it failed. Here is the log:
Preparing backup on krb4.cs.rutgers.edu
Local roles match globally used roles, proceeding.
Backing up userRoot in CS-RUTGERS-EDU to LDIF
Waiting for LDIF to finish
Backing up CS-RUTGERS-EDU
Waiting for BAK to finish
cannot connect to 'ldapi://%2Frun%2Fslapd-CS-RUTGERS-EDU.socket':
The ipa-backup command failed. See /var/log/ipabackup.log for more information
I'm wondering whether there's a bug that only happens under load.
We're been doing this in production for years with no trouble up to RHEL 9.2.
5 months
possible issue with ipa-backup on RHEL 9.3
by Charles Hedrick
I just upgraded one of three servers from RHEL 9.2. to 9.3. I have a clone of our three servers, on which all three have been upgraded to 9.3.
All of the servers run a cron job
/sbin/ipa-backup --online --data > /usr/local/scripts/ipa-backup.log 2>&1
The LDAP server hung (needed kill -9) at about the time that job ran, on the production server but not the testing copy. Obviously I can't prove that the backup caused the hang, but it's suspicious. I've commented out the cron job, since the backup isn't actually all the useful. If we have to restore we'd use a snapshot of the VM.
The backup completed successfully on the clone. On the production server it failed. Here is the log:
Preparing backup on krb4.cs.rutgers.edu
Local roles match globally used roles, proceeding.
Backing up userRoot in CS-RUTGERS-EDU to LDIF
Waiting for LDIF to finish
Backing up CS-RUTGERS-EDU
Waiting for BAK to finish
cannot connect to 'ldapi://%2Frun%2Fslapd-CS-RUTGERS-EDU.socket':
The ipa-backup command failed. See /var/log/ipabackup.log for more information
I'm wondering whether there's a bug that only happens under load.
We're been doing this in production for years with no trouble up to RHEL 9.2.
5 months
Grant extra permissions to System Accounts
by RA
Hi,
I created a System Account as indicated at https://www.freeipa.org/page/HowTo/LDAP#system-accounts and it works as expected (it is used to perform LDAP bind for authentication in my email application). The problem comes when I try to use it to read additional attributes (required by postfix-ldap) in my users, for example, mailAlternateAddress (it is not able to read the attribute).
As a workaround, I created a "regular" LDAP user and assigned the permissions/roles required and it works, however, I don't think that a dedicated user should be created to perform this task, am I wrong?
Considering the scenario described, I have a couple of questions:
1. Is it possible to grant permissions to a System Account to read those attributes? (I tried to add it to the roles/permissions using memberOf but it didn't allow to add those attributes, I got a permissions error even if I used my admin account to run ldapmodify)
2. What would be the "correct" way to do the configuration? (I mean regular user? other?)
Thanks
5 months
Grant extra permissions to System Accounts
by RA
Hi,
I created a System Account as indicated at https://www.freeipa.org/page/HowTo/LDAP#system-accounts and it works as expected (it is used to perform LDAP bind for authentication in my email application). The problem comes when I try to use it to read additional attributes (required by postfix-ldap) in my users, for example, mailAlternateAddress (it is not able to read the attribute).
As a workaround, I created a "regular" LDAP user and assigned the permissions/roles required and it works, however, I don't think that a dedicated user should be created to perform this task, am I wrong?
Considering the scenario described, I have a couple of questions:
1. Is it possible to grant permissions to a System Account to read those attributes? (I tried to add it to the roles/permissions using memberOf but it didn't allow to add those attributes, I got a permissions error even if I used my admin account to run ldapmodify)
2. What would be the "correct" way to do the configuration? (I mean regular user? other?)
Thanks
5 months
How to change default OTP algorithm from sha1 to sha256 or sha512
by Jeff Kirkley
Hello,
Very new to freeipa but find it to be very powerful and very capable. I have been using Keycloak for some time now and am interested in using FreeIPA as a OTP password provider (if possible).
I am running FreeIPA 4.10.2 and am having problems with a plain/regular user creating a OTP token from the GUI and the created token is based as SHA1. I would like for it to be either SHA256 or SHA512. I have spent many hours scouring the web and am unable to find where this is a user-selectable option under the user's login. I am also unable to find it in any of the settings while logged in as admin. I did make a change to:
/usr/share/ipa/ui/js/freeipa/app.js
and changed the default to sha512 and if I were to login as admin and create a new token for a user (testuser), I do have a GUI ability to choose the strength of the OTP token. However, this is not presented to a normal user (belonging to only ipausers group).
How do I change/enable this ability for a plain user to login to freeipa server, create a OTP token and change the hash strength?
Any help would be greatly appreciated.
Thanks,
Jeff
5 months, 1 week
