I think I removed too much certs, with CNRS2 certs in /etc/dirsrv/slapd-LIX-POLYTECHNIQUE-FR, ipa-ca-install works better but I still have an error at the end
Done configuring certificate server (pki-tomcatd). ipaclient.install.ipa_certupdate: ERROR failed to update LIX.POLYTECHNIQUE.FR IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d dbm:/etc/httpd/alias -A -n LIX.POLYTECHNIQUE.FR IPA CA -t CT,C,C -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Resubmitting certmonger request '20231013171553' timed out, please check the request manually
ipa-certupdate give similar errorr
trying https://ipa3.lix.polytechnique.fr/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa3.lix.polytechnique.fr/ipa/json' did not receive Kerberos credentials The ipa-certupdate command failed. [root@ipa3 ~]# kinit admin Password for admin@LIX.POLYTECHNIQUE.FR: [root@ipa3 ~]# ipa-certupdate trying https://ipa3.lix.polytechnique.fr/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa3.lix.polytechnique.fr/ipa/json' trying https://ipa3.lix.polytechnique.fr/ipa/session/json [try 1]: Forwarding 'ca_is_enabled/1' to json server 'https://ipa3.lix.polytechnique.fr/ipa/session/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa3.lix.polytechnique.fr/ipa/session/json' failed to update LIX.POLYTECHNIQUE.FR IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d dbm:/etc/httpd/alias -A -n LIX.POLYTECHNIQUE.FR IPA CA -t CT,C,C -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255
Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
and ipa-server-upgrade seem to work
Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/11]: stopping directory server [2/11]: saving configuration [3/11]: disabling listeners [4/11]: enabling DS global lock [5/11]: disabling Schema Compat [6/11]: starting directory server [7/11]: updating schema [8/11]: upgrading server [9/11]: stopping directory server [10/11]: restoring configuration [11/11]: starting directory server Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] Publish directory already set to new location [Verifying that CA proxy configuration is correct] [Verifying that KDC configuration is using ipa-kdb backend] [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Enable sidgen and extdom plugins by default] [Updating HTTPD service IPA configuration] [Updating HTTPD service IPA WSGI configuration] Nothing to do for configure_httpd_wsgi_conf [Updating mod_nss protocol versions] Protocol versions already updated [Updating mod_nss cipher suite] [Updating mod_nss enabling OCSP] [Fixing trust flags in /etc/httpd/alias] [Moving HTTPD service keytab to gssproxy] [Removing self-signed CA] [Removing Dogtag 9 CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] DNS is not configured [Ensuring minimal number of connections] DNS is not configured [Updating GSSAPI configuration in DNS] DNS is not configured [Updating pid-file configuration in DNS] DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration] Configuring certmonger to stop tracking system certificates for CA Certmonger certificate renewal configuration updated [Enable PKIX certificate path discovery and validation] [Authorizing RA Agent to modify profiles] [Authorizing RA Agent to manage lightweight CAs] [Ensuring Lightweight CAs container exists in Dogtag database] [Adding default OCSP URI configuration] pki-tomcat configuration changed, restart pki-tomcat [Ensuring CA is using LDAPProfileSubsystem] [Migrating certificate profiles to LDAP] [Ensuring presence of included profiles] [Add default CA ACL] Default CA ACL already added [Set up lightweight CA key retrieval] Creating principal Retrieving keytab Creating Custodia keys Configuring key retriever [Create systemd-user hbac service and rule] hbac service systemd-user already exists [Setup PKINIT] [Enable certauth] The IPA services were upgraded The ipa-server-upgrade command was successful
But ipactl status do not show pki-tomcatd Service
Thank you
Frederic
Frédéric AYRAULT Administrateur Systèmes et Réseaux Laboratoire d'Informatique de l'Ecole polytechnique http://www.lix.polytechnique.fr fred@lix.polytechnique.fr
Le 13/10/2023 à 17:31, Frederic Ayrault a écrit :
Bonjour,
Le 13/10/2023 à 10:24, Florence Blanc-Renaud a écrit :
Hi,
Your current situation: there was a self-signed IPA CA in one of the servers, the replica was created without the CA role then extracted from the original topology. This means there are traces of the CA installation in the new replica but nothing to actually provide the service.
So my answer really depends on what you want to achieve. If the new replica will never be connected any more to the previous topology, you could follow Fraser's blog about Removing the CA from a FreeIPA deployment https://frasertweedale.github.io/blog-redhat/posts/2019-10-24-removing-ipa-ca.html on the replica after it has been removed from the original topology, ensure that everything is cleanup and call ipa-ca-install on the new replica. This would ensure there is a new CA private key completely different from the original one. Please note that this blog provides instructions but 1. this is not an officially supported procedure and 2. the instructions intend to remove the CA, not reinstall a new one later on.
With Fraser's blog, I managed to remove some certs.
Frederic Ayrault via FreeIPA-users wrote:
I think I removed too much certs, with CNRS2 certs in /etc/dirsrv/slapd-LIX-POLYTECHNIQUE-FR, ipa-ca-install works better but I still have an error at the end
Done configuring certificate server (pki-tomcatd). ipaclient.install.ipa_certupdate: ERROR failed to update LIX.POLYTECHNIQUE.FR IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d dbm:/etc/httpd/alias -A -n LIX.POLYTECHNIQUE.FR IPA CA -t CT,C,C -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255
I'd recommend you try this command manually to see what the whole error is. You'll need to quote the nickname 'LIX....'
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Resubmitting certmonger request '20231013171553' timed out, please check the request manually
ipa-certupdate give similar errorr
trying https://ipa3.lix.polytechnique.fr/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa3.lix.polytechnique.fr/ipa/json' did not receive Kerberos credentials The ipa-certupdate command failed. [root@ipa3 ~]# kinit admin Password for admin@LIX.POLYTECHNIQUE.FR: [root@ipa3 ~]# ipa-certupdate trying https://ipa3.lix.polytechnique.fr/ipa/json [try 1]: Forwarding 'schema' to json server 'https://ipa3.lix.polytechnique.fr/ipa/json' trying https://ipa3.lix.polytechnique.fr/ipa/session/json [try 1]: Forwarding 'ca_is_enabled/1' to json server 'https://ipa3.lix.polytechnique.fr/ipa/session/json' [try 1]: Forwarding 'ca_find/1' to json server 'https://ipa3.lix.polytechnique.fr/ipa/session/json' failed to update LIX.POLYTECHNIQUE.FR IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d dbm:/etc/httpd/alias -A -n LIX.POLYTECHNIQUE.FR IPA CA -t CT,C,C -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255
Running it manually should give more details why it failed.
Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful
and ipa-server-upgrade seem to work
Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/11]: stopping directory server [2/11]: saving configuration [3/11]: disabling listeners [4/11]: enabling DS global lock [5/11]: disabling Schema Compat [6/11]: starting directory server [7/11]: updating schema [8/11]: upgrading server [9/11]: stopping directory server [10/11]: restoring configuration [11/11]: starting directory server Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] Publish directory already set to new location [Verifying that CA proxy configuration is correct] [Verifying that KDC configuration is using ipa-kdb backend] [Fix DS schema file syntax] Syntax already fixed [Removing RA cert from DS NSS database] RA cert already removed [Enable sidgen and extdom plugins by default] [Updating HTTPD service IPA configuration] [Updating HTTPD service IPA WSGI configuration] Nothing to do for configure_httpd_wsgi_conf [Updating mod_nss protocol versions] Protocol versions already updated [Updating mod_nss cipher suite] [Updating mod_nss enabling OCSP] [Fixing trust flags in /etc/httpd/alias] [Moving HTTPD service keytab to gssproxy] [Removing self-signed CA] [Removing Dogtag 9 CA] [Checking for deprecated KDC configuration files] [Checking for deprecated backups of Samba configuration files] [Add missing CA DNS records] IPA CA DNS records already processed [Removing deprecated DNS configuration options] DNS is not configured [Ensuring minimal number of connections] DNS is not configured [Updating GSSAPI configuration in DNS] DNS is not configured [Updating pid-file configuration in DNS] DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured DNS is not configured [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration] Configuring certmonger to stop tracking system certificates for CA Certmonger certificate renewal configuration updated [Enable PKIX certificate path discovery and validation] [Authorizing RA Agent to modify profiles] [Authorizing RA Agent to manage lightweight CAs] [Ensuring Lightweight CAs container exists in Dogtag database] [Adding default OCSP URI configuration] pki-tomcat configuration changed, restart pki-tomcat [Ensuring CA is using LDAPProfileSubsystem] [Migrating certificate profiles to LDAP] [Ensuring presence of included profiles] [Add default CA ACL] Default CA ACL already added [Set up lightweight CA key retrieval] Creating principal Retrieving keytab Creating Custodia keys Configuring key retriever [Create systemd-user hbac service and rule] hbac service systemd-user already exists [Setup PKINIT] [Enable certauth] The IPA services were upgraded The ipa-server-upgrade command was successful
But ipactl status do not show pki-tomcatd Service
Because the CA installation failed it isn't registered as an IPA service.
rob
Thank you
Frederic
Frédéric AYRAULT Administrateur Systèmes et Réseaux Laboratoire d'Informatique de l'Ecole polytechnique http://www.lix.polytechnique.fr fred@lix.polytechnique.fr
Le 13/10/2023 à 17:31, Frederic Ayrault a écrit :
Bonjour,
Le 13/10/2023 à 10:24, Florence Blanc-Renaud a écrit :
Hi,
Your current situation: there was a self-signed IPA CA in one of the servers, the replica was created without the CA role then extracted from the original topology. This means there are traces of the CA installation in the new replica but nothing to actually provide the service.
So my answer really depends on what you want to achieve. If the new replica will never be connected any more to the previous topology, you could follow Fraser's blog about Removing the CA from a FreeIPA deployment https://frasertweedale.github.io/blog-redhat/posts/2019-10-24-removing-ipa-ca.html on the replica after it has been removed from the original topology, ensure that everything is cleanup and call ipa-ca-install on the new replica. This would ensure there is a new CA private key completely different from the original one. Please note that this blog provides instructions but 1. this is not an officially supported procedure and 2. the instructions intend to remove the CA, not reinstall a new one later on.
With Fraser's blog, I managed to remove some certs.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Bonsoir,
Le 13/10/2023 à 22:20, Rob Crittenden via FreeIPA-users a écrit :
Frederic Ayrault via FreeIPA-users wrote:
Done configuring certificate server (pki-tomcatd). ipaclient.install.ipa_certupdate: ERROR failed to update LIX.POLYTECHNIQUE.FR IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d dbm:/etc/httpd/alias -A -n LIX.POLYTECHNIQUE.FR IPA CA -t CT,C,C -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255
I'd recommend you try this command manually to see what the whole error is. You'll need to quote the nickname 'LIX....'
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Resubmitting certmonger request '20231013171553' timed out, please check the request manually
ipa-certupdate give similar errorr
Running it manually should give more details why it failed.
rob
I got a lot of errors
Oct 16 14:14:46 ipa3.lix.polytechnique.fr krb5kdc[1932](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 193.55.176.91: LOOKING_UP_SERVER: authtime 0, ldap/ipa3.lix.polytechnique.fr@LIX.POLYTECHNIQUE.FR for ldap/ipa2.lix.polytechnique.fr@LIX.POLYTECHNIQUE.FR, Server not found in Kerberos database
ipa2 was the server used for ipa-replica-prepare, the is now only ipa3 in the ipa-replica-manage list and ipa3 is not in any other ipa-replica-manage list
I have delete cn=sig/ipa2.lix.polytechnique.fr,cn=custodia,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr and cn=enc/ipa2.lix.polytechnique.fr,cn=custodia,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr from the ldap base (I can not find any ipa2)
Regards,
Frederic
Bonjour,
Le 16/10/2023 à 21:13, Frederic Ayrault a écrit :
Bonsoir,
Le 13/10/2023 à 22:20, Rob Crittenden via FreeIPA-users a écrit :
Frederic Ayrault via FreeIPA-users wrote:
Done configuring certificate server (pki-tomcatd). ipaclient.install.ipa_certupdate: ERROR failed to update LIX.POLYTECHNIQUE.FR IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d dbm:/etc/httpd/alias -A -n LIX.POLYTECHNIQUE.FR IPA CA -t CT,C,C -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255
I'd recommend you try this command manually to see what the whole error is. You'll need to quote the nickname 'LIX....'
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Resubmitting certmonger request '20231013171553' timed out, please check the request manually
ipa-certupdate give similar errorr
Running it manually should give more details why it failed.
rob
I got a lot of errors
Oct 16 14:14:46 ipa3.lix.polytechnique.fr krb5kdc[1932](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 193.55.176.91: LOOKING_UP_SERVER: authtime 0, ldap/ipa3.lix.polytechnique.fr@LIX.POLYTECHNIQUE.FR for ldap/ipa2.lix.polytechnique.fr@LIX.POLYTECHNIQUE.FR, Server not found in Kerberos database
ipa2 was the server used for ipa-replica-prepare, the is now only ipa3 in the ipa-replica-manage list and ipa3 is not in any other ipa-replica-manage list
I have delete cn=sig/ipa2.lix.polytechnique.fr,cn=custodia,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr and cn=enc/ipa2.lix.polytechnique.fr,cn=custodia,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr from the ldap base (I can not find any ipa2)
Regards,
Frederic
I create replication between 2 servers ipa3 and ipa4, ipa-ca-install works, I can now see pki-tomcatd Service when I run ipactl status but it is STOPPED
And when try to start it manually ( systemctl start pki-tomcatd@pki-tomcat.service ), I get errors
SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve.
certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u CNRS2-Standard - CNRS C,, LIX.POLYTECHNIQUE.FR IPA CA CT,C,C ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u CNRS2 - CNRS ,,
I tried to remove CNRS certs but then ipa-ca-install fails ( IndexError: list index out of range )
Thank you
Regards,
Frederic
Frederic Ayrault wrote:
Bonjour,
Le 16/10/2023 à 21:13, Frederic Ayrault a écrit :
Bonsoir,
Le 13/10/2023 à 22:20, Rob Crittenden via FreeIPA-users a écrit :
Frederic Ayrault via FreeIPA-users wrote:
Done configuring certificate server (pki-tomcatd). ipaclient.install.ipa_certupdate: ERROR failed to update LIX.POLYTECHNIQUE.FR IPA CA in /etc/httpd/alias: Command '/usr/bin/certutil -d dbm:/etc/httpd/alias -A -n LIX.POLYTECHNIQUE.FR IPA CA -t CT,C,C -a -f /etc/httpd/alias/pwdfile.txt' returned non-zero exit status 255
I'd recommend you try this command manually to see what the whole error is. You'll need to quote the nickname 'LIX....'
Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up.
Resubmitting certmonger request '20231013171553' timed out, please check the request manually
ipa-certupdate give similar errorr
Running it manually should give more details why it failed.
rob
I got a lot of errors
Oct 16 14:14:46 ipa3.lix.polytechnique.fr krb5kdc[1932](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 193.55.176.91: LOOKING_UP_SERVER: authtime 0, ldap/ipa3.lix.polytechnique.fr@LIX.POLYTECHNIQUE.FR for ldap/ipa2.lix.polytechnique.fr@LIX.POLYTECHNIQUE.FR, Server not found in Kerberos database
ipa2 was the server used for ipa-replica-prepare, the is now only ipa3 in the ipa-replica-manage list and ipa3 is not in any other ipa-replica-manage list
I have delete cn=sig/ipa2.lix.polytechnique.fr,cn=custodia,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr
and cn=enc/ipa2.lix.polytechnique.fr,cn=custodia,cn=ipa,cn=etc,dc=lix,dc=polytechnique,dc=fr from the ldap base (I can not find any ipa2)
Regards,
Frederic
I create replication between 2 servers ipa3 and ipa4, ipa-ca-install works, I can now see pki-tomcatd Service when I run ipactl status but it is STOPPED
So if I've followed this thread correctly, what you're doing is:
- Taking replica ipa3? and forcibly disconnecting it from an existing IPA installation - Trying to install a CA on it
Where does ipa4 come in? It's a replica if ipa3?
And when try to start it manually ( systemctl start pki-tomcatd@pki-tomcat.service ), I get errors
SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve.
You need to lookin /var/log/pki/pki-tomcat/ca/debug<perhaps-date>
You need to find in that log the last time the CA started and work down from there to find an error, or errors. The usual bottom-up approach won't work because the CA is persistent in trying to start and will often move past errors that may be transient.
certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u CNRS2-Standard - CNRS C,, LIX.POLYTECHNIQUE.FR IPA CA CT,C,C ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u CNRS2 - CNRS ,,
I tried to remove CNRS certs but then ipa-ca-install fails ( IndexError: list index out of range )
I presume they are necessary because your existing HTTP and LDAP certificates are essentially externally signed. So this is expected. Well, maybe not a traceback.
rob
Thank you
Regards,
Frederic
Le 17/10/2023 à 17:23, Rob Crittenden a écrit :
So if I've followed this thread correctly, what you're doing is:
- Taking replica ipa3? and forcibly disconnecting it from an existing
IPA installation
This is just because my IPA is in production so I removed ipa3 for the tests
- Trying to install a CA on it
that's right
Where does ipa4 come in? It's a replica if ipa3?
yes ipa4 is a replica of ipa3 and I used it for the ipa-replica-install to reinstall ipa3
I was not able to remove ipa3 from ipa2 (a production replica)
this is another "creative" procedure
And when try to start it manually ( systemctl start pki-tomcatd@pki-tomcat.service ), I get errors
SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve.
You need to lookin /var/log/pki/pki-tomcat/ca/debug<perhaps-date>
I will check that
You need to find in that log the last time the CA started and work down from there to find an error, or errors. The usual bottom-up approach won't work because the CA is persistent in trying to start and will often move past errors that may be transient.
certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u CNRS2-Standard - CNRS C,, LIX.POLYTECHNIQUE.FR IPA CA CT,C,C ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u CNRS2 - CNRS ,,
I tried to remove CNRS certs but then ipa-ca-install fails ( IndexError: list index out of range )
I presume they are necessary because your existing HTTP and LDAP certificates are essentially externally signed. So this is expected. Well, maybe not a traceback.
I would like to delete CNRS2 certs, but ipa-ca-install does not work and I remove them after ipa-ca-install ipactl restart does work
rob
Thank you
Frederic
Hi,
On Tue, Oct 17, 2023 at 5:47 PM Frederic Ayrault fred@lix.polytechnique.fr wrote:
Le 17/10/2023 à 17:23, Rob Crittenden a écrit :
So if I've followed this thread correctly, what you're doing is:
- Taking replica ipa3? and forcibly disconnecting it from an existing
IPA installation
This is just because my IPA is in production so I removed ipa3 for the tests
- Trying to install a CA on it
that's right
Where does ipa4 come in? It's a replica if ipa3?
yes ipa4 is a replica of ipa3 and I used it for the ipa-replica-install to reinstall ipa3
I was not able to remove ipa3 from ipa2 (a production replica)
this is another "creative" procedure
And when try to start it manually ( systemctl start pki-tomcatd@pki-tomcat.service ), I get errors
SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve.
You need to lookin /var/log/pki/pki-tomcat/ca/debug<perhaps-date>
I will check that
You need to find in that log the last time the CA started and work down from there to find an error, or errors. The usual bottom-up approach won't work because the CA is persistent in trying to start and will often move past errors that may be transient.
certutil -d /etc/pki/pki-tomcat/alias/ -L
Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI
auditSigningCert cert-pki-ca u,u,Pu Server-Cert cert-pki-ca u,u,u CNRS2-Standard - CNRS C,, LIX.POLYTECHNIQUE.FR IPA CA CT,C,C ocspSigningCert cert-pki-ca u,u,u subsystemCert cert-pki-ca u,u,u CNRS2 - CNRS ,,
I tried to remove CNRS certs but then ipa-ca-install fails ( IndexError: list index out of range )
I presume they are necessary because your existing HTTP and LDAP certificates are essentially externally signed. So this is expected. Well, maybe not a traceback.
I would like to delete CNRS2 certs, but ipa-ca-install does not work and I remove them after ipa-ca-install ipactl restart does work
CNRS2 and CNRS2-Standard are part of the CA chain that issued your HTTP and LDAP server certificates, they should not be removed. When you install a new embedded IPA CA, it doesn't replace the existing HTTP and LDAP server certificates with new ones issued by IPA CA. You will be able to remove CNRS2 and CNRS2-standard (IF you don't use any other cert issued by them) only when the HTTP and LDAP server certs are replaced with new ones issued by IPA CA (which is a manual operation).
flo
rob
Thank you
Frederic
Bonjour,
Le 18/10/2023 à 15:33, Florence Blanc-Renaud a écrit :
Hi,
CNRS2 and CNRS2-Standard are part of the CA chain that issued your HTTP and LDAP server certificates, they should not be removed. When you install a new embedded IPA CA, it doesn't replace the existing HTTP and LDAP server certificates with new ones issued by IPA CA. You will be able to remove CNRS2 and CNRS2-standard (IF you don't use any other cert issued by them) only when the HTTP and LDAP server certs are replaced with new ones issued by IPA CA (which is a manual operation).
I was thinking/hoping the new IPA CA will replace the old one :-(
How should I proceed ?
flo
Thank you
Regards,
Frederic
Hi,
On Wed, Oct 18, 2023 at 4:11 PM Frederic Ayrault fred@lix.polytechnique.fr wrote:
Bonjour,
Le 18/10/2023 à 15:33, Florence Blanc-Renaud a écrit :
Hi,
CNRS2 and CNRS2-Standard are part of the CA chain that issued your HTTP and LDAP server certificates, they should not be removed. When you install a new embedded IPA CA, it doesn't replace the existing HTTP and LDAP server certificates with new ones issued by IPA CA. You will be able to remove CNRS2 and CNRS2-standard (IF you don't use any other cert issued by them) only when the HTTP and LDAP server certs are replaced with new ones issued by IPA CA (which is a manual operation).
I was thinking/hoping the new IPA CA will replace the old one :-(
How should I proceed ?
The process is documented in
https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/7/htm...
You need to follow the steps using the integrated CA (the new one that you installed with ipa-ca-install). flo
flo
Thank you
Regards,
Frederic
Florence Blanc-Renaud wrote:
Hi,
On Wed, Oct 18, 2023 at 4:11 PM Frederic Ayrault <fred@lix.polytechnique.fr mailto:fred@lix.polytechnique.fr> wrote:
Bonjour, Le 18/10/2023 à 15:33, Florence Blanc-Renaud a écrit :
Hi, CNRS2 and CNRS2-Standard are part of the CA chain that issued your HTTP and LDAP server certificates, they should not be removed. When you install a new embedded IPA CA, it doesn't replace the existing HTTP and LDAP server certificates with new ones issued by IPA CA. You will be able to remove CNRS2 and CNRS2-standard (IF you don't use any other cert issued by them) only when the HTTP and LDAP server certs are replaced with new ones issued by IPA CA (which is a manual operation).
I was thinking/hoping the new IPA CA will replace the old one :-( How should I proceed ?
The process is documented in https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/7/htm...
You need to follow the steps using the integrated CA (the new one that you installed with ipa-ca-install).
Right, so ipa-ca-install did effectively replace the old CA, but you're not done yet. As Flo points out, the HTTP and 389-ds (and who knows about PKINIT) certs were issued by a 3rd party.
At this point in the thread I can't even remember which version of RHEL/IPA you are running. I think it's RHEL 7 so here are some pointers there.
You should be able to use certmonger to get new certs but it will involve some more manual effort.
See what your nicknames are before starting to ensure there is no conflict.
# certutil -L -d /etc/httpd/alias # certutil -L -d /etc/dirsrv/slapd-REALM
I'm using the IPA-standard Server-Cert in these examples
# getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -D <IPA FQDN> -K HTTP/<IPA FQDN> -C /usr/libexec/ipa/certmonger/restart_httpd -v -w
Assuming I didn't mess up the command and the request status goes into MONITORING you can try switching to the new cert. Edit /etc/httpd/conf.d/nss.conf and replace the value of NSSNickname with Server-Cert. I'd save a copy of that value just in case so you need to go back.
Restart Apache.
If all went well you now have an IPA-issued certificate for it.
For 389. Remember that REALM here replaces dots with dashes, so EXAMPLE.TEST becomes EXAMPLE-TEST
# getcert request -d /etc/dirsrv/slapd-INSTANCE -n Server-Cert -p /etc/dirsrv/slapd-INSTANCE/pwdfile.txt -D <IPA FQDN> -K ldap/<IPA FQDN> -C "/usr/libexec/ipa/certmonger/restart_dirsrv REALM" -v -w
Once it issues stop the dirsrv service (important, don't forget)
Edit /etc/dirsrv/slapd-REALM/dse.ldif
Replace the value in nsSSLPersonalitySSL with Server-Cert
Restart dirsrv
Hopefully profit.
The old certificates will still be in the NSS database(s) if you need to revert.
rob
Thank you Regards, Frederic
Bonsoir
Le 18/10/2023 à 19:43, Rob Crittenden via FreeIPA-users a écrit :
Right, so ipa-ca-install did effectively replace the old CA, but you're not done yet. As Flo points out, the HTTP and 389-ds (and who knows about PKINIT) certs were issued by a 3rd party.
At this point in the thread I can't even remember which version of RHEL/IPA you are running. I think it's RHEL 7 so here are some pointers there.
Sorry if this thread is . You are right I am using Centos7
You should be able to use certmonger to get new certs but it will involve some more manual effort.
See what your nicknames are before starting to ensure there is no conflict.
# certutil -L -d /etc/httpd/alias # certutil -L -d /etc/dirsrv/slapd-REALM
I'm using the IPA-standard Server-Cert in these examples
# getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -D <IPA FQDN> -K HTTP/<IPA FQDN> -C /usr/libexec/ipa/certmonger/restart_httpd -v -w
Assuming I didn't mess up the command and the request status goes into MONITORING you can try switching to the new cert. Edit /etc/httpd/conf.d/nss.conf and replace the value of NSSNickname with Server-Cert. I'd save a copy of that value just in case so you need to go back.
Restart Apache.
If all went well you now have an IPA-issued certificate for it.
For 389. Remember that REALM here replaces dots with dashes, so EXAMPLE.TEST becomes EXAMPLE-TEST
# getcert request -d /etc/dirsrv/slapd-INSTANCE -n Server-Cert -p /etc/dirsrv/slapd-INSTANCE/pwdfile.txt -D <IPA FQDN> -K ldap/<IPA FQDN> -C "/usr/libexec/ipa/certmonger/restart_dirsrv REALM" -v -w
Once it issues stop the dirsrv service (important, don't forget)
Edit /etc/dirsrv/slapd-REALM/dse.ldif
Replace the value in nsSSLPersonalitySSL with Server-Cert
Restart dirsrv
Hopefully profit.
The old certificates will still be in the NSS database(s) if you need to revert.
rob
I will try thoese commands and Florence's link
Thank you for your help
Regards,
Frederic
Bonjour,
Le 18/10/2023 à 19:43, Rob Crittenden via FreeIPA-users a écrit :
# getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -D <IPA FQDN> -K HTTP/<IPA FQDN> -C /usr/libexec/ipa/certmonger/restart_httpd -v -w
This command does not work
New signing request "20231020100840" added. State NEWLY_ADDED_READING_KEYINFO, stuck: no. State GENERATING_KEY_PAIR, stuck: no. State GENERATING_CSR, stuck: no. State NEED_CA, stuck: yes.
if I understand correctly this is because pki-tomcatd Service is stopped
when I do a ipactl restart, I get a lot of errors
SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve.
Thank you
Regards,
Frederic
Frederic Ayrault wrote:
Bonjour,
Le 18/10/2023 à 19:43, Rob Crittenden via FreeIPA-users a écrit :
# getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -D <IPA FQDN> -K HTTP/<IPA FQDN> -C /usr/libexec/ipa/certmonger/restart_httpd -v -w
This command does not work
New signing request "20231020100840" added. State NEWLY_ADDED_READING_KEYINFO, stuck: no. State GENERATING_KEY_PAIR, stuck: no. State GENERATING_CSR, stuck: no. State NEED_CA, stuck: yes.
if I understand correctly this is because pki-tomcatd Service is stopped
If the CA isn't running then there is no way to replace the certs.
when I do a ipactl restart, I get a lot of errors
SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve.
On startup ipactl checks the CA status to see what is going on and times out after IIRC 300 seconds.
You'll need to dig into the PKI logs to see why it isn't starting.
rob
Thank you
Regards,
Frederic
Bonjour,
Thank you Rob and Florence for your help
It looks it looks difficult to switch to internal CA, hopefully with some help it seems easier to setup another exernal CA
Regards,
Frederic
Frédéric AYRAULT Administrateur Systèmes et Réseaux Laboratoire d'Informatique de l'Ecole polytechnique http://www.lix.polytechnique.fr fred@lix.polytechnique.fr
Le 23/10/2023 à 15:37, Rob Crittenden a écrit :
Frederic Ayrault wrote:
Bonjour,
Le 18/10/2023 à 19:43, Rob Crittenden via FreeIPA-users a écrit :
# getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -D <IPA FQDN> -K HTTP/<IPA FQDN> -C /usr/libexec/ipa/certmonger/restart_httpd -v -w
This command does not work
New signing request "20231020100840" added. State NEWLY_ADDED_READING_KEYINFO, stuck: no. State GENERATING_KEY_PAIR, stuck: no. State GENERATING_CSR, stuck: no. State NEED_CA, stuck: yes.
if I understand correctly this is because pki-tomcatd Service is stopped
If the CA isn't running then there is no way to replace the certs.
when I do a ipactl restart, I get a lot of errors
SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve.
On startup ipactl checks the CA status to see what is going on and times out after IIRC 300 seconds.
You'll need to dig into the PKI logs to see why it isn't starting.
rob
Thank you
Regards,
Frederic
Bonjour,
Le 18/10/2023 à 16:57, Florence Blanc-Renaud via FreeIPA-users a écrit :
Hi,
The process is documented in https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/7/htm...
You need to follow the steps using the integrated CA (the new one that you installed with ipa-ca-install).
If I understand correctly I need to extract the crt but I do not know how :-(
What is the password for --pin ( /etc/httpd/alias/pwdfile.txt ) ?
flo
Thank you
Regards,
Frederic
freeipa-users@lists.fedorahosted.org