[Freeipa-users] Re: CA Subsystem certificate
I take that back. Replication is working on 4/6 servers. If I add a user on any of those 4 it shows up on the other 3. The 2 outliers don't seem to pick up the new user. If I check the 2 outliers I get this Error (18) Replication error acquiring replica: Incremental update transient error. Backing off, will retry update later. (transient error) Which seems to be saying that it's just delayed, which can sometimes happen in an MMR setup. I will recheck these 2 later to see if they eventually pick up the new test user I've created and that is present on 4 of them. -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
I tried adding a test user on one of the servers that returned that warning and the new user didn't appear on the others. So maybe replication is broken. -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Alright, so 'ipa idrange-find' returns the same values on all 6 servers. However, ldapsearch -x -D 'cn=Directory Manager' -W -b 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' returns different results on 1 (the one where I don't get that warning with the healthcheck) The other 5 return dnaMagicRegen: -1 dnaMaxValue: 1100 dnaNextValue: 1101 dnaScope: dc=ipa,dc=superb,dc=net dnaSharedCfgDN: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=ipa,dc=superb,dc=net dnaThreshold: 500 dnaType: uidNumber dnaType: gidNumber objectClass: top objectClass: extensibleObject Which seems to match your blog post from 2015 about this. Since I cannot be sure which IPA server will be used when enrolling new hosts, would it be best to try to fix this? I suppose the same can be said for when new users are added. If done manually I can be sure it will be done on the same host, but we have an internal system that also creates the user in IPA and I think that would just use whichever one is closest. -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Travis West via FreeIPA-users wrote:
> Thanks Rob! New certs are all replicated and all IPA services are started on
> all 6 servers.
> I can perform 'ipa cert-show 1' on all 6 and get the expected result.
>
> As a sanity check I did run the ipa-healthcheck on all 6 servers. One of
> them came back fine, the other 5 returned
>
> [
> {
> "source": "ipahealthcheck.ipa.dna",
> "kw": {
> "msg": "No DNA range defined. If no masters define a range then users
> and groups cannot be created.",
> "range_start": 0,
> "next_start": 0,
> "next_max": 0,
> "range_max": 0
> },
> "uuid": "70636197-0b3e-4424-b509-1aa7f8be084d",
> "duration": "0.706384",
> "when": "20240405170045Z",
> "check": "IPADNARangeCheck",
> "result": "WARNING"
> }
> ]
>
> Now it's just a WARNING, and since the one didn't return it (they're all
> denoted as MASTER) maybe it's okay?
It just means that when you add users or groups you do it against the
same IPA server. If you do it on others then it will split the range
between them as needed. Not a bad thing but it gets complex if you add
and remove a lot of servers, particularly older ones. I made changes a
few years ago to try to capture ranges that would otherwise be lost but
it's sort of a best effort kind of thing.
The purpose if this is to ensure that at least one server has a range.
Currently healthcheck only validates the server it is running on and
doesn't do much cluster-wide checking.
rob
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Thanks Rob! New certs are all replicated and all IPA services are started on
all 6 servers.
I can perform 'ipa cert-show 1' on all 6 and get the expected result.
As a sanity check I did run the ipa-healthcheck on all 6 servers. One of them
came back fine, the other 5 returned
[
{
"source": "ipahealthcheck.ipa.dna",
"kw": {
"msg": "No DNA range defined. If no masters define a range then users and
groups cannot be created.",
"range_start": 0,
"next_start": 0,
"next_max": 0,
"range_max": 0
},
"uuid": "70636197-0b3e-4424-b509-1aa7f8be084d",
"duration": "0.706384",
"when": "20240405170045Z",
"check": "IPADNARangeCheck",
"result": "WARNING"
}
]
Now it's just a WARNING, and since the one didn't return it (they're all
denoted as MASTER) maybe it's okay?
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Travis West via FreeIPA-users wrote: > The problem was definitely the ra-agent.pem. I generated a new one and > imported it to ~/.dogtag/nssdb, LDAP and placed the pem and key in > /var/lib/ipa/ > > Now I can verify the certificate with the openssl verify command. > Additionally the error in the UI is gone and running an 'ipa cert-show 1' > works and doesn't return the error I was seeing. > > The last piece here is replicating the new certificates to other 5 hosts in > the cluster. Is there a method to do that or should I import the new certs > manually on the other hosts? If you put the certificates into cn=,cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX then the other servers will pick them up assuming that replication is working. rob -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
The problem was definitely the ra-agent.pem. I generated a new one and imported it to ~/.dogtag/nssdb, LDAP and placed the pem and key in /var/lib/ipa/ Now I can verify the certificate with the openssl verify command. Additionally the error in the UI is gone and running an 'ipa cert-show 1' works and doesn't return the error I was seeing. The last piece here is replicating the new certificates to other 5 hosts in the cluster. Is there a method to do that or should I import the new certs manually on the other hosts? -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
This morning I thought I had found what I was missing, import the new RA cert to ~/.dogtag/nssdb, which I've done and now all the places I know about the RA cert matches. # certutil -L -d /root/.dogtag/nssdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Certificate Authority - IPA..NET CT,C,C IPA RA - IPA..NET u,u,u # certutil -L -d /root/.dogtag/nssdb -n "IPA RA - IPA..NET" -a -BEGIN CERTIFICATE- MIID6jCC...ssifAg== -END CERTIFICATE- # certutil -L -d /root/.dogtag/nssdb -n "IPA RA - IPA..NET" | grep Serial Serial Number: 7 (0x7) # ldapsearch -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # ipara, people, ipaca dn: uid=ipara,ou=people,o=ipaca description: 2;7;CN=Certificate Authority,O=IPA..NET;CN=IPA RA,O=IPA..NET userCertificate:: MIID6jCC...ssifAg== uid: ipara sn: ipara usertype: agentType userstate: 1 objectClass: cmsuser objectClass: top objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: person cn: ipara # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 # cat /var/lib/ipa/ra-agent.pem -BEGIN CERTIFICATE- MIID6jCC...ssifAg== -END CERTIFICATE- but the openssl verify command with the -show_chain flag still seems to fail ]# openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt /var/lib/ipa/ra-agent.pem usage: verify [-verbose] [-CApath path] [-CAfile file] [-trusted_first] [-purpose purpose] [-crl_check] [-no_alt_chains] [-attime timestamp] [-engine e] cert1 cert2 ... recognized usages: sslclient SSL client sslserver SSL server nssslserver Netscape SSL server smimesign S/MIME signing smimeencryptS/MIME encryption crlsign CRL signing any Any Purpose ocsphelper OCSP helper timestampsign Time Stamp signing -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
I spun up a new server and did a fresh install of IPA. On that server if I run the command I get a better result # openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt /var/lib/ipa/ra-agent.pem /var/lib/ipa/ra-agent.pem: OK Chain: depth=0: O = AUTH..NET, CN = IPA RA (untrusted) depth=1: O = AUTH..NET, CN = Certificate Authority So I must be missing something with the RA cert. It's definitely in LDAP. I've read that it should also be present in /etc/httpd/alias/ NSS DB, but that directory is empty on the fresh install so I cannot confirm. The ASN.1 appears to be correct on the ra-agent.pem when I check $ openssl asn1parse -inform pem -in ra-agent.pem 37:d=5 hl=2 l= 3 prim: OBJECT :organizationName 42:d=5 hl=2 l= 14 prim: UTF8STRING :IPA..NET 58:d=3 hl=2 l= 30 cons: SET 60:d=4 hl=2 l= 28 cons: SEQUENCE 62:d=5 hl=2 l= 3 prim: OBJECT :commonName 67:d=5 hl=2 l= 21 prim: UTF8STRING :Certificate Authority 90:d=2 hl=2 l= 30 cons: SEQUENCE 92:d=3 hl=2 l= 13 prim: UTCTIME :240322132444Z 107:d=3 hl=2 l= 13 prim: UTCTIME :260312132444Z 122:d=2 hl=2 l= 42 cons: SEQUENCE 124:d=3 hl=2 l= 23 cons: SET 126:d=4 hl=2 l= 21 cons: SEQUENCE 128:d=5 hl=2 l= 3 prim: OBJECT :organizationName 133:d=5 hl=2 l= 14 prim: UTF8STRING :IPA..NET 149:d=3 hl=2 l= 15 cons: SET 151:d=4 hl=2 l= 13 cons: SEQUENCE 153:d=5 hl=2 l= 3 prim: OBJECT :commonName 158:d=5 hl=2 l= 6 prim: PRINTABLESTRING :IPA RA This was another cert that had an incorrect Principle attached and was regenerated. I may have messed up something there, but I'm not sure what. I do have a copy of the ra-agent.pem (and matching key) with the correct Principle from 2019. I can put this in place on the broken server, but even with rolling the time back I'm not sure it will get renewed. -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
If I run that command manually it doesn't appear to do anything except output 'recognized usages" If I try it without the -show_chain flag I get # openssl verify -verbose -CAfile /etc/ipa/ca.crt /var/lib/ipa/ra-agent.pem /var/lib/ipa/ra-agent.pem: O = IPA..NET, CN = IPA RA error 20 at 0 depth lookup:unable to get local issuer certificate The only information in the access log while healthcheck is running is a number of these [04/Apr/2024:15:09:46 +] "POST https://ipa1-sea2.ipa..net:443/ca/agent/ca/displayBySerial HTTP/1.1" 403 229 But those coincide with the healthcheck checking other certificates managed by certmonger where the error shown by healthcheck is [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1822)", -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Travis West via FreeIPA-users wrote:
> Rob,
>
> I installed the ipa-healthcheck that you got to work on CentOS 7, and run it.
> Got a couple of errors regarding the RA Agent cert:
>
> [
> {
> "source": "ipahealthcheck.ipa.certs",
> "kw": {
> "msg": "Certificate validation for /var/lib/ipa/ra-agent.pem failed: ",
> "reason": "",
> "key": "/var/lib/ipa/ra-agent.pem"
> },
> "uuid": "a855346c-4998-4415-a819-ce83048e174e",
> "duration": "0.100214",
> "when": "20240404141916Z",
> "check": "IPAOpenSSLChainValidation",
> "result": "ERROR"
> },
> {
> "source": "ipahealthcheck.ipa.certs",
> "kw": {
> "msg": "RA agent not found in LDAP"
> },
> "uuid": "b6efdb6c-ca33-4421-bdc5-c449e7d64591",
> "duration": "0.027569",
> "when": "20240404141916Z",
> "check": "IPARAAgent",
> "result": "ERROR"
> }
It runs: openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt
/var/lib/ipa/ra-agent.pem
> That first error, I'm not sure about what kind of validation it's performing.
> In my asn.1 output earlier I did include the ra-agent.pem and it looks like
> it's correctly signed.
> As far as the "RA agent not found in LDAP", it looks to me like it is, and it
> matches the cert in /var/lib/ipa/ra-agent.pem
>
> # ldapsearch -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # ipara, people, ipaca
> dn: uid=ipara,ou=people,o=ipaca
> description: 2;7;CN=Certificate Authority,O=IPA..NET;CN=IPA
> RA,O=IPA..NET
> userCertificate:: MIID6j...ssifAg==
> uid: ipara
> sn: ipara
> usertype: agentType
> userstate: 1
> objectClass: cmsuser
> objectClass: top
> objectClass: organizationalPerson
> objectClass: inetOrgPerson
> objectClass: person
> cn: ipara
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> # cat ra-agent.pem
> -BEGIN CERTIFICATE-
> MIID6j...ssifAg==
> -END CERTIFICATE-
Watch the 389-ds access log (buffer) while healthcheck runs. You should
see the failed search and the reason may be enlightening (or not).
You can also add --debug to the command and may be that will help.
rob
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Rob,
I installed the ipa-healthcheck that you got to work on CentOS 7, and run it.
Got a couple of errors regarding the RA Agent cert:
[
{
"source": "ipahealthcheck.ipa.certs",
"kw": {
"msg": "Certificate validation for /var/lib/ipa/ra-agent.pem failed: ",
"reason": "",
"key": "/var/lib/ipa/ra-agent.pem"
},
"uuid": "a855346c-4998-4415-a819-ce83048e174e",
"duration": "0.100214",
"when": "20240404141916Z",
"check": "IPAOpenSSLChainValidation",
"result": "ERROR"
},
{
"source": "ipahealthcheck.ipa.certs",
"kw": {
"msg": "RA agent not found in LDAP"
},
"uuid": "b6efdb6c-ca33-4421-bdc5-c449e7d64591",
"duration": "0.027569",
"when": "20240404141916Z",
"check": "IPARAAgent",
"result": "ERROR"
}
That first error, I'm not sure about what kind of validation it's performing.
In my asn.1 output earlier I did include the ra-agent.pem and it looks like
it's correctly signed.
As far as the "RA agent not found in LDAP", it looks to me like it is, and it
matches the cert in /var/lib/ipa/ra-agent.pem
# ldapsearch -D "cn=directory manager" -W -b uid=ipara,ou=people,o=ipaca
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# ipara, people, ipaca
dn: uid=ipara,ou=people,o=ipaca
description: 2;7;CN=Certificate Authority,O=IPA..NET;CN=IPA
RA,O=IPA..NET
userCertificate:: MIID6j...ssifAg==
uid: ipara
sn: ipara
usertype: agentType
userstate: 1
objectClass: cmsuser
objectClass: top
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: person
cn: ipara
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
# cat ra-agent.pem
-BEGIN CERTIFICATE-
MIID6j...ssifAg==
-END CERTIFICATE-
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
This morning I tried running ipa-server-upgrade to see if that would help. It ultimately failed, but in a different spot and with a different error: 2024-04-04T11:36:42Z DEBUG The CA status is: running 2024-04-04T11:36:42Z INFO [Ensuring CA is using LDAPProfileSubsystem] 2024-04-04T11:36:42Z INFO [Migrating certificate profiles to LDAP] 2024-04-04T11:36:42Z DEBUG Created connection context.ldap2_140461768893264 2024-04-04T11:36:42Z DEBUG flushing ldapi://%2fvar%2frun%2fslapd-IPA--NET.socket from SchemaCache 2024-04-04T11:36:42Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-IPA--NET.socket conn= 2024-04-04T11:36:42Z DEBUG Destroyed connection context.ldap2_140461768893264 2024-04-04T11:36:42Z DEBUG request GET https://ipa1-sea2.ipa..net:8443/ca/rest/account/login 2024-04-04T11:36:42Z DEBUG request body '' 2024-04-04T11:36:42Z DEBUG httplib request failed: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 220, in _httplib_request conn.request(method, uri, body=request_body, headers=headers) File "/usr/lib64/python2.7/httplib.py", line 1041, in request self._send_request(method, url, body, headers) File "/usr/lib64/python2.7/httplib.py", line 1075, in _send_request self.endheaders(body) File "/usr/lib64/python2.7/httplib.py", line 1037, in endheaders self._send_output(message_body) File "/usr/lib64/python2.7/httplib.py", line 881, in _send_output self.send(msg) File "/usr/lib64/python2.7/httplib.py", line 843, in send self.connect() File "/usr/lib64/python2.7/httplib.py", line 1260, in connect server_hostname=sni_hostname) File "/usr/lib64/python2.7/ssl.py", line 348, in wrap_socket _context=self) File "/usr/lib64/python2.7/ssl.py", line 609, in __init__ self.do_handshake() File "/usr/lib64/python2.7/ssl.py", line 831, in do_handshake self._sslobj.do_handshake() SSLError: [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:618) 2024-04-04T11:36:42Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2024-04-04T11:36:42Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 54, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 2085, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1952, in upgrade_configuration ca_enable_ldap_profile_subsystem(ca) File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 396, in ca_enable_ldap_profile_subsystem cainstance.migrate_profiles_to_ldap() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1814, in migrate_profiles_to_ldap _create_dogtag_profile(profile_id, profile_data, overwrite=False) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1820, in _create_dogtag_profile with api.Backend.ra_certprofile as profile_api: File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1298, in __enter__ method='GET' File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 167, in https_request method=method, headers=headers) File "/usr/lib/python2.7/site-packages/ipapython/dogtag.py", line 229, in _httplib_request raise NetworkError(uri=uri, error=str(e)) 2024-04-04T11:36:42Z DEBUG The ipa-server-upgrade command failed, exception: NetworkError: cannot connect to 'https://ipa1-sea2.ipa..net:8443/ca/rest/account/login': [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:618) 2024-04-04T11:36:42Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: Again with the 'unknown ca' message. I've confirmed that the ca.crt is the same that is listed as the caSigngingCert in /etc/pki/pki-tomcat/alias and is the one found at /etc/ipa/ca.crt. I believe my output of asn.1 for each certificate also shows all the certificates signed by the CA, so I'm not sure what certificate it's complaining about coming from an unknown CA. -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Here is the output of validation # certutil -V -u V -d /etc/pki/pki-tomcat/alias -n 'Server-Cert cert-pki-ca' -e -f /etc/pki/pki-tomcat/alias/pwdfile.txt certutil: certificate is valid And for the asn.1 of the Audit, OCSP, Subsystem, and RA certs $ openssl asn1parse -inform pem -in audit.crt 37:d=5 hl=2 l= 3 prim: OBJECT:organizationName 42:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 58:d=3 hl=2 l= 30 cons: SET 60:d=4 hl=2 l= 28 cons: SEQUENCE 62:d=5 hl=2 l= 3 prim: OBJECT:commonName 67:d=5 hl=2 l= 21 prim: UTF8STRING:Certificate Authority 90:d=2 hl=2 l= 30 cons: SEQUENCE 92:d=3 hl=2 l= 13 prim: UTCTIME :240403113826Z 107:d=3 hl=2 l= 13 prim: UTCTIME :340401113826Z 122:d=2 hl=2 l= 44 cons: SEQUENCE 124:d=3 hl=2 l= 23 cons: SET 126:d=4 hl=2 l= 21 cons: SEQUENCE 128:d=5 hl=2 l= 3 prim: OBJECT:organizationName 133:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 149:d=3 hl=2 l= 17 cons: SET 151:d=4 hl=2 l= 15 cons: SEQUENCE 153:d=5 hl=2 l= 3 prim: OBJECT:commonName 158:d=5 hl=2 l= 8 prim: UTF8STRING:CA Audit $ openssl asn1parse -inform pem -in subsystem.crt 37:d=5 hl=2 l= 3 prim: OBJECT:organizationName 42:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 58:d=3 hl=2 l= 30 cons: SET 60:d=4 hl=2 l= 28 cons: SEQUENCE 62:d=5 hl=2 l= 3 prim: OBJECT:commonName 67:d=5 hl=2 l= 21 prim: UTF8STRING:Certificate Authority 90:d=2 hl=2 l= 30 cons: SEQUENCE 92:d=3 hl=2 l= 13 prim: UTCTIME :240403113547Z 107:d=3 hl=2 l= 13 prim: UTCTIME :340401113547Z 122:d=2 hl=2 l= 48 cons: SEQUENCE 124:d=3 hl=2 l= 23 cons: SET 126:d=4 hl=2 l= 21 cons: SEQUENCE 128:d=5 hl=2 l= 3 prim: OBJECT:organizationName 133:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 149:d=3 hl=2 l= 21 cons: SET 151:d=4 hl=2 l= 19 cons: SEQUENCE 153:d=5 hl=2 l= 3 prim: OBJECT:commonName 158:d=5 hl=2 l= 12 prim: UTF8STRING:CA Subsystem $ openssl asn1parse -inform pem -in ocsp.crt 37:d=5 hl=2 l= 3 prim: OBJECT:organizationName 42:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 58:d=3 hl=2 l= 30 cons: SET 60:d=4 hl=2 l= 28 cons: SEQUENCE 62:d=5 hl=2 l= 3 prim: OBJECT:commonName 67:d=5 hl=2 l= 21 prim: UTF8STRING:Certificate Authority 90:d=2 hl=2 l= 30 cons: SEQUENCE 92:d=3 hl=2 l= 13 prim: UTCTIME :240403113248Z 107:d=3 hl=2 l= 13 prim: UTCTIME :340401113248Z 122:d=2 hl=2 l= 50 cons: SEQUENCE 124:d=3 hl=2 l= 23 cons: SET 126:d=4 hl=2 l= 21 cons: SEQUENCE 128:d=5 hl=2 l= 3 prim: OBJECT:organizationName 133:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 149:d=3 hl=2 l= 23 cons: SET 151:d=4 hl=2 l= 21 cons: SEQUENCE 153:d=5 hl=2 l= 3 prim: OBJECT:commonName 158:d=5 hl=2 l= 14 prim: UTF8STRING:OCSP Subsystem $ openssl asn1parse -inform pem -in ra-agent.pem 37:d=5 hl=2 l= 3 prim: OBJECT:organizationName 42:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 58:d=3 hl=2 l= 30 cons: SET 60:d=4 hl=2 l= 28 cons: SEQUENCE 62:d=5 hl=2 l= 3 prim: OBJECT:commonName 67:d=5 hl=2 l= 21 prim: UTF8STRING:Certificate Authority 90:d=2 hl=2 l= 30 cons: SEQUENCE 92:d=3 hl=2 l= 13 prim: UTCTIME :240322132444Z 107:d=3 hl=2 l= 13 prim: UTCTIME :260312132444Z 122:d=2 hl=2 l= 42 cons: SEQUENCE 124:d=3 hl=2 l= 23 cons: SET 126:d=4 hl=2 l= 21 cons: SEQUENCE 128:d=5 hl=2 l= 3 prim: OBJECT:organizationName 133:d=5 hl=2 l= 14 prim: UTF8STRING:IPA..NET 149:d=3 hl=2 l= 15 cons: SET 151:d=4 hl=2 l= 13 cons: SEQUENCE 153:d=5 hl=2 l= 3 prim: OBJECT:commonName 158:d=5 hl=2 l= 6 prim: PRINTABLESTRING :IPA RA I tried a resubmit on the ra-agent cert with getcert and this was the result Request ID '20190322032004': status: CA_UNREACHABLE ca-error: Error 35 connecting to https://ipa1-sea2.ipa..net:8443/ca/agent/ca/profileReview: SSL connect error. stuck: no -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Travis West via FreeIPA-users wrote:
> In the apache error log I found this that is generated when, in the UI, I try
> to access Authentication > Certificates > Certificate Authorities.
>
> [Wed Apr 03 16:33:28.439180 2024] [:error] [pid 19048] ipa: INFO:
> [jsonserver_session] twest@IPA..NET: cert_find(None, version=u'2.230'):
> SUCCESS
> [Wed Apr 03 16:33:30.661528 2024] [:warn] [pid 19601] [client
> IP.ADD.RE.SS:61691] failed to set perms (3140) on file
> (/var/run/ipa/ccaches/twest@IPA..NET)!, referer:
> https://ipa1-sea2.ipa..net/ipa/ui/
> [Wed Apr 03 16:33:30.720054 2024] [:error] [pid 19047] ipa: INFO:
> [jsonserver_session] twest@IPA..NET: ca_find(u'', sizelimit=0,
> version=u'2.230', pkey_only=True): SUCCESS
> [Wed Apr 03 16:33:30.731584 2024] [:warn] [pid 19601] [client
> IP.ADD.RE.SS:61691] failed to set perms (3140) on file
> (/var/run/ipa/ccaches/twest@IPA..NET)!, referer:
> https://ipa1-sea2.ipa..net/ipa/ui/
> [Wed Apr 03 16:33:30.831428 2024] [:error] [pid 19055] Bad remote server
> certificate: -8179
> [Wed Apr 03 16:33:30.831479 2024] [:error] [pid 19055] SSL Library Error:
> -8179 Certificate is signed by an unknown issuer
> [Wed Apr 03 16:33:30.831557 2024] [:error] [pid 19055] Re-negotiation
> handshake failed: Not accepted by client!?
> [Wed Apr 03 16:33:30.831672 2024] [:error] [pid 19055] SSL Library Error:
> -12116 Unknown
> [Wed Apr 03 16:33:30.832809 2024] [:error] [pid 19048] ipa: INFO:
> twest@IPA..NET: batch: ca_show(u'ipa'): NetworkError
> [Wed Apr 03 16:33:30.833300 2024] [:error] [pid 19048] ipa: INFO:
> [jsonserver_session] twest@IPA..NET: batch(({u'params': ([u'ipa'], {}),
> u'method': u'ca_show'},), version=u'2.230'): SUCCESS
>
> but no indication of which certificate it is complaining about. I thought
> maybe the IPA RA cert, but that is definitely signed by this CA and doesn't
> expires on 2026.
> The certs I generated and imported to /etc/pki/pki-tomcat/alias are also
> signed by the CA.
Apache, via the IPA API, is acting as the client in this case. So Apache
doesn't trust the CA certificate (unlikely), or the Server-Cert cert-pki-ca.
You can validate it directly with:
# certutil -V -u V -d /etc/pki/pki-tomcat/alias -n 'Server-Cert
cert-pki-ca' -e -f /etc/pki/pki-tomcat/alias/pwdfile.txt
Also, given the subject issues you ran into I guess I'd also verify that
the ASN.1 is correct in the issued certificates. This will be easier
since you have them as PEM files already:
# openssl asn1parse -inform pem -in /path/to/cert.pem
In the output you should see each component of the issuer and subject
broken out like:
...
37:d=5 hl=2 l= 3 prim: OBJECT:organizationName
42:d=5 hl=2 l= 12 prim: UTF8STRING:EXAMPLE.TEST
56:d=3 hl=2 l= 30 cons: SET
58:d=4 hl=2 l= 28 cons: SEQUENCE
60:d=5 hl=2 l= 3 prim: OBJECT:commonName
65:d=5 hl=2 l= 21 prim: UTF8STRING:Certificate Authority
88:d=2 hl=2 l= 30 cons: SEQUENCE
90:d=3 hl=2 l= 13 prim: UTCTIME :240221205457Z
105:d=3 hl=2 l= 13 prim: UTCTIME :260221205457Z
120:d=2 hl=2 l= 50 cons: SEQUENCE
122:d=3 hl=2 l= 21 cons: SET
124:d=4 hl=2 l= 19 cons: SEQUENCE
126:d=5 hl=2 l= 3 prim: OBJECT:organizationName
131:d=5 hl=2 l= 12 prim: UTF8STRING:EXAMPLE.TEST
145:d=3 hl=2 l= 25 cons: SET
147:d=4 hl=2 l= 23 cons: SEQUENCE
149:d=5 hl=2 l= 3 prim: OBJECT:commonName
154:d=5 hl=2 l= 16 prim: UTF8STRING:ipa.example.test
...
And finally, and this might be kinda nutty, but you can use certmonger
to force issue a new certificate using the resubmit command. I'd
snapshot things but that could be a way to get freshly issued certs that
might play more nicely with others.
rob
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
In the apache error log I found this that is generated when, in the UI, I try
to access Authentication > Certificates > Certificate Authorities.
[Wed Apr 03 16:33:28.439180 2024] [:error] [pid 19048] ipa: INFO:
[jsonserver_session] twest@IPA..NET: cert_find(None, version=u'2.230'):
SUCCESS
[Wed Apr 03 16:33:30.661528 2024] [:warn] [pid 19601] [client
IP.ADD.RE.SS:61691] failed to set perms (3140) on file
(/var/run/ipa/ccaches/twest@IPA..NET)!, referer:
https://ipa1-sea2.ipa..net/ipa/ui/
[Wed Apr 03 16:33:30.720054 2024] [:error] [pid 19047] ipa: INFO:
[jsonserver_session] twest@IPA..NET: ca_find(u'', sizelimit=0,
version=u'2.230', pkey_only=True): SUCCESS
[Wed Apr 03 16:33:30.731584 2024] [:warn] [pid 19601] [client
IP.ADD.RE.SS:61691] failed to set perms (3140) on file
(/var/run/ipa/ccaches/twest@IPA..NET)!, referer:
https://ipa1-sea2.ipa..net/ipa/ui/
[Wed Apr 03 16:33:30.831428 2024] [:error] [pid 19055] Bad remote server
certificate: -8179
[Wed Apr 03 16:33:30.831479 2024] [:error] [pid 19055] SSL Library Error: -8179
Certificate is signed by an unknown issuer
[Wed Apr 03 16:33:30.831557 2024] [:error] [pid 19055] Re-negotiation handshake
failed: Not accepted by client!?
[Wed Apr 03 16:33:30.831672 2024] [:error] [pid 19055] SSL Library Error:
-12116 Unknown
[Wed Apr 03 16:33:30.832809 2024] [:error] [pid 19048] ipa: INFO:
twest@IPA..NET: batch: ca_show(u'ipa'): NetworkError
[Wed Apr 03 16:33:30.833300 2024] [:error] [pid 19048] ipa: INFO:
[jsonserver_session] twest@IPA..NET: batch(({u'params': ([u'ipa'], {}),
u'method': u'ca_show'},), version=u'2.230'): SUCCESS
but no indication of which certificate it is complaining about. I thought
maybe the IPA RA cert, but that is definitely signed by this CA and doesn't
expires on 2026.
The certs I generated and imported to /etc/pki/pki-tomcat/alias are also signed
by the CA.
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
No I didn't go back in time, I generated new certificates and imported them to NSS DB after deleting the ones that contained Principles that had other hosts listed. I then updated the CS.cfg with the cert and certreq values, and made sure the CA Subsystem cert in NSS DB matched what is in LDAP. I'm not sure what logs to look at. /etc/pki/pki-tomcat/ca/selftest has no errors /etc/pki/pki-tomcat/ca/system has the last error from before I got ipa to fully start. The debug log has a lot of information, but nothing that looks like an error. I've got no expired certs # getcert list | grep expires expires: 2025-01-26 11:37:18 UTC expires: 2025-01-26 11:37:04 UTC expires: 2026-03-12 13:24:44 UTC expires: 2034-04-01 11:38:26 UTC expires: 2034-04-01 11:32:48 UTC expires: 2034-04-01 11:35:47 UTC expires: 2037-03-21 04:43:44 UTC expires: 2024-12-24 11:37:06 UTC expires: 2025-01-26 11:41:35 UTC Trust attributes all look correct in /etc/pki/pki-tomcat/alias # certutil -L -d . Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI subsystemCert cert-pki-cau,u,u ocspSigningCert cert-pki-ca u,u,u caSigningCert cert-pki-caCTu,Cu,Cu Server-Cert cert-pki-ca u,u,u auditSigningCert cert-pki-ca u,u,Pu Certmonger tracking shows correct now with the Subject having the CN and O in the correct order. -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Travis West via FreeIPA-users wrote: > Spoke too soon. If I try to get a new certificate on an enrolled host I get > this > > status: CA_UNREACHABLE > ca-error: Server at https://ipa1-sea2.ipa..net/ipa/xml failed request, > will retry: 907 (RPC failed at server. cannot connect to > 'https://ipa1-sea2.ipa..net:443/ca/rest/account/login': [SSL: > SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1822)). > > This reflected in the UI if I go to Authentication > Certificates > > Certificate Authorities where I see the same error. > > The IPA server listed there is the one where all services started via ipactl > start in my previous update. I think you need to take a look at fresh logs to see what failed. It may point to why. I assume you went back in time to 2019 and then leaped forward 2 years at a pop, renewing as you went, and now it's present day? rob -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Spoke too soon. If I try to get a new certificate on an enrolled host I get this status: CA_UNREACHABLE ca-error: Server at https://ipa1-sea2.ipa..net/ipa/xml failed request, will retry: 907 (RPC failed at server. cannot connect to 'https://ipa1-sea2.ipa..net:443/ca/rest/account/login': [SSL: SSL_HANDSHAKE_FAILURE] ssl handshake failure (_ssl.c:1822)). This reflected in the UI if I go to Authentication > Certificates > Certificate Authorities where I see the same error. The IPA server listed there is the one where all services started via ipactl start in my previous update. -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Swapping the O and CN in the req did the trick for the getcert list output Request ID '20190322032031': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=IPA..NET subject: CN=CA Subsystem,O=IPA..NET expires: 2034-04-01 11:35:47 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190322032030': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=IPA..NET subject: CN=OCSP Subsystem,O=IPA..NET expires: 2034-04-01 11:32:48 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190322032029': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=IPA..NET subject: CN=CA Audit,O=IPA..NET expires: 2034-04-01 11:38:26 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes I then updated LDAP with the new CA Subsystem cert, so that and the serial for it match # ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso Enter LDAP Password: dn: uid=pkidbuser,ou=people,o=ipaca userCertificate:: MIIDNjRXOm8Q== description: 2;4;CN=Certificate Authority,O=IPA..NET;CN=CA Subsystem,O=IPA..NET seeAlso: CN=CA Subsystem,O=IPA..NET # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a -BEGIN CERTIFICATE- MIIDNjRXOm8Q== -END CERTIFICATE- # certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial Serial Number: 4 (0x4) After this I tried an 'ipactl restart --ignore-service-failures' but pki-tomcat still failed to start. So I tried manually stopping that service using systemctl stop pki-tomcatd@pki-tomcat.service then issuing an 'ipactl start --ignore-service-failures. This time all services seem to have started # ipactl start --ignore-service-failures Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting httpd Service Starting ipa-custodia Service Starting pki-tomcatd Service Starting ipa-otpd Service Starting ipa-dnskeysyncd Service ipa: INFO: The ipactl command was successful If I login to the UI I can now browse to Authentication > Certificates, where as before I got an error when going here. So far so good. Now, I've got 5 other servers in this cluster, all denoted as Master, with this server set as the CA Renewal Master. Do I need to repeat the certificate import steps on the other 5 servers or is there a way to replicate over the new certificates to the other hosts? -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
> On Wed, Apr 3, 2024 at 5:24 AM Travis West via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org wrote: > > That's exactly my point. I would expect subject and issuer to display the > components in the same order (ending with O=IPA..NET). The subject was > provided to openssl req command, you can try to provide it in the reverse > order. If I look at the p12 file I created from the it has them listed in the correct order for Subject, but the Issuer line is reversed from what getcert shows subject=/CN=OCSP Subsystem/O=IPA..NET issuer=/O=IPA..NET/CN=Certificate Authority subject=/CN=CA Subsystem/O=IPA..NET issuer=/O=IPA..NET/CN=Certificate Authority subject=/CN=CA Audit/O=IPA..NET issuer=/O=IPA..NET/CN=Certificate Authority The CSR was created using this command openssl req -new -sha256 -key ocsp.key -subj "/CN=OCSP Subsystem /O=IPA.SUPERB.NET" -out ocsp.csr The certificate was requested using this command x509 -req -in ocsp.csr -CA ca.crt -CAkey ca.key -set_serial 2 -out ocsp.crt -days 3650 -sha256 So you're saying in that CSR req to swap CN and O for that -subj flag? -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
On Wed, Apr 3, 2024 at 5:24 AM Travis West via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > > Hi, > > > > On Tue, Apr 2, 2024 at 8:50 PM Travis West via FreeIPA-users < > > freeipa-users(a)lists.fedorahosted.org wrote: > > > > As Rob wrote, it's not a problem that getcert list, OpenssL and NSS > > libraries show the subject in a DN order (RFC2253) or DN reverse order, > but > > I find it suspect that issuer and subject have picked inconsistent order. > > In my f35 instance, getcert list shows the following: > > issuer: CN=Certificate Authority,O=IPA.TEST > > subject: CN=CA Subsystem,O=IPA.TEST > > > > I'm not sure I follow. My getcert list output looks like that, except the > CN and O are reversed in the Subject line > That's exactly my point. I would expect subject and issuer to display the components in the same order (ending with O=IPA..NET). The subject was provided to openssl req command, you can try to provide it in the reverse order. flo > > issuer: CN=Certificate Authority,O=IPA..NET > subject: O=IPA..NET,CN=OCSP Subsystem > > issuer: CN=Certificate Authority,O=IPA..NET > subject: O=IPA..NET,CN=CA Subsystem > > issuer: CN=Certificate Authority,O=IPA..NET > subject: O=IPA..NET,CN=CA Audit > -- > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
> Hi, > > On Tue, Apr 2, 2024 at 8:50 PM Travis West via FreeIPA-users < > freeipa-users(a)lists.fedorahosted.org wrote: > > As Rob wrote, it's not a problem that getcert list, OpenssL and NSS > libraries show the subject in a DN order (RFC2253) or DN reverse order, but > I find it suspect that issuer and subject have picked inconsistent order. > In my f35 instance, getcert list shows the following: > issuer: CN=Certificate Authority,O=IPA.TEST > subject: CN=CA Subsystem,O=IPA.TEST > I'm not sure I follow. My getcert list output looks like that, except the CN and O are reversed in the Subject line issuer: CN=Certificate Authority,O=IPA..NET subject: O=IPA..NET,CN=OCSP Subsystem issuer: CN=Certificate Authority,O=IPA..NET subject: O=IPA..NET,CN=CA Subsystem issuer: CN=Certificate Authority,O=IPA..NET subject: O=IPA..NET,CN=CA Audit -- ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: CA Subsystem certificate
Hi, On Tue, Apr 2, 2024 at 8:50 PM Travis West via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > Okay, I've generated new certs that don't have the extra space. Once > those were imported to the NSS DB I also updated the CS.cfg with the new > cert and certreq vaules for OCSP, Audit, and Subsystem. > I also did an ldapsearch for the Subsystem certificate to make sure it > matches. I then tried to run ipa-server-upgrade, but it failed. > > Tracking Requests: > > Request ID '20190322032031': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=IPA..NET > subject: O=IPA..NET,CN=CA Subsystem > As Rob wrote, it's not a problem that getcert list, OpenssL and NSS libraries show the subject in a DN order (RFC2253) or DN reverse order, but I find it suspect that issuer and subject have picked inconsistent order. In my f35 instance, getcert list shows the following: issuer: CN=Certificate Authority,O=IPA.TEST subject: CN=CA Subsystem,O=IPA.TEST flo expires: 2034-03-31 17:57:15 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '20190322032030': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=IPA..NET > subject: O=IPA..NET,CN=OCSP Subsystem > expires: 2034-03-31 18:02:29 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > > Request ID '20190322032029': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=IPA..NET > subject: O=IPA..NET,CN=CA Audit > expires: 2034-03-31 18:00:11 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > > Subsystem in LDAP matches the NSS DB > > # ldapsearch -LLL -D 'cn=directory manager' -W -b > uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso > Enter LDAP Password: > dn: uid=pkidbuser,ou=people,o=ipaca > userCertificate:: MIIDNjCCA...EyISxo3w== > description: 2;4;CN=Certificate Authority,O=IPA..NET;CN=CA > Subsystem,O=IPA.***.NET > seeAlso: CN=CA Subsystem,O=IPA.NET > > [root@ipa1-sea2 log]# certutil -L -d /etc/pki/pki-tomcat/alias -n > 'subsystemCert cert-pki-ca' -a > -BEGIN CERTIFICATE- > MIIDNjCCA...EyISxo3w== > -END CERTIFICATE- > [root@ipa1-sea2 log]# certutil -L -d /etc/pki/pki-tomcat/alias -n > 'subsystemCert cert-pki-ca' | grep Serial > Serial Number: 4 (0x4) > > *note the Serial in LDAP is '4' while in NSS DB it shows as 4 (0x4) not > sure if this is the issue. > > Output of ipa-server-upgrade > > # ipa-server-upgrade > 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] > IPA server upgrade
[Freeipa-users] Re: CA Subsystem certificate
Okay, I've generated new certs that don't have the extra space. Once those were imported to the NSS DB I also updated the CS.cfg with the new cert and certreq vaules for OCSP, Audit, and Subsystem. I also did an ldapsearch for the Subsystem certificate to make sure it matches. I then tried to run ipa-server-upgrade, but it failed. Tracking Requests: Request ID '20190322032031': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=IPA..NET subject: O=IPA..NET,CN=CA Subsystem expires: 2034-03-31 17:57:15 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190322032030': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=IPA..NET subject: O=IPA..NET,CN=OCSP Subsystem expires: 2034-03-31 18:02:29 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20190322032029': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=IPA..NET subject: O=IPA..NET,CN=CA Audit expires: 2034-03-31 18:00:11 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Subsystem in LDAP matches the NSS DB # ldapsearch -LLL -D 'cn=directory manager' -W -b uid=pkidbuser,ou=people,o=ipaca userCertificate description seeAlso Enter LDAP Password: dn: uid=pkidbuser,ou=people,o=ipaca userCertificate:: MIIDNjCCA...EyISxo3w== description: 2;4;CN=Certificate Authority,O=IPA..NET;CN=CA Subsystem,O=IPA.***.NET seeAlso: CN=CA Subsystem,O=IPA.NET [root@ipa1-sea2 log]# certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a -BEGIN CERTIFICATE- MIIDNjCCA...EyISxo3w== -END CERTIFICATE- [root@ipa1-sea2 log]# certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' | grep Serial Serial Number: 4 (0x4) *note the Serial in LDAP is '4' while in NSS DB it shows as 4 (0x4) not sure if this is the issue. Output of ipa-server-upgrade # ipa-server-upgrade 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] IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. CA did not start in 300.0s Output in the /var/log/pki/pki-tomcat/ca/system log while the ugprade was running 2024-04-02T18:30:11Z DEBUG response body 'Apache Tomcat/7.0.76 - Error report