Toma Morris via FreeIPA-users wrote:
> I have taken over an existing deployment of FreeIPA that has not been updated
> in some time. I would like to update it, but am getting a recurring error and
> do not know how to fix it. Currently it is FreeIPA v4.9.6, running on Fedora
> 34, running in VMs on VMWare. The current deployment is two replicas that
> both act as write nodes and CA hosts (hostnames freeipa1 and freeipa2). There
> were previously two additional nodes that were shut down (hostnames freeipa
> and freeipa3 -- according to what I can figure out, they failed without being
> removed gracefully, so there are some traces of them left in the system).
>
> ipa-healthcheck returns a number of errors. The following appear to be the
> most relevant to my eye. The "unknown ca" error message is repeated in most
> of them. I can provide the whole response if needed:
>
> ```
> Internal server error HTTPSConnectionPool(host='freeipa.local.domain',
> port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3
> (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at
> 0x7f6a5da14190>: Failed to establish a new connection: [Errno 113] No route
> to host'))
> [
> ...
> {
> "source": "pki.server.healthcheck.meta.csconfig",
> "check": "CADogtagCertsConfigCheck",
> "result": "ERROR",
> "uuid": "6945db10-a79b-4d17-84e3-1e4a91bdfbeb",
> "when": "20240822190635Z",
> "duration": "0.229479",
> "kw": {
> "key": "ca_signing",
> "nickname": "caSigningCert cert-pki-ca",
> "directive": "ca.signing.cert",
> "configfile": "/var/lib/pki/pki-tomcat/ca/conf/CS.cfg",
> "msg": "Certificate 'caSigningCert cert-pki-ca' does not match the
> value of ca.signing.cert in /var/lib/pki/pki-tomcat/ca/conf/CS.cfg"
> }
> },
> ...
> {
> "source": "ipahealthcheck.dogtag.ca",
> "check": "DogtagCertsConnectivityCheck",
> "result": "ERROR",
> "uuid": "9fbbcb00-4d48-4dad-95b2-8d0738f1d540",
> "when": "20240822190637Z",
> "duration": "0.016692",
> "kw": {
> "key": "cert_show_1",
> "msg": "Request for certificate failed, cannot connect to
> 'https://freeipa1.local.domain:443/ca/rest/certs/1': [SSL:
> TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2633)"
> }
> },
> ...
> {
> "source": "ipahealthcheck.ipa.idns",
> "check": "IPADNSSystemRecordsCheck",
> "result": "WARNING",
> "uuid": "d873830f-3e7f-4c12-b61a-567dca63bc0e",
> "when": "20240822190645Z",
> "duration": "0.040974",
> "kw": {
> "key": "ca_count_a_rec",
> "msg": "Got {count} ipa-ca A records, expected {expected}",
> "count": 3,
> "expected": 2
> }
> }
> ]
> ```
>
> Currently this prevents me from viewing any certificates in the UI, and also
> prevents doing most operations involved with either updating the existing
> nodes or adding a new one. If I try to promote a new replica, I get this
> error. Likewise if I upgrade the OS on one of the existing nodes and try
> `ipactl restart`. I have tried replacing the CA cert and got a success
> message, but no change in behavior, and ipa-cert-fix finds nothing to do:
>
> ```
> [root@freeipa1 ~]# ipa-cacert-manage -t C,, install
> /home/tmorris/incommonCA-2024.ca
> Installing CA certificate, please wait
> Verified CN=InCommon RSA Server CA 2,O=Internet2,C=US
> CA certificate successfully installed
> The ipa-cacert-manage command was successful
> [root@freeipa1 ~]# ipa-cert-fix
> Nothing to do.
> The ipa-cert-fix command was successful
> ```
>
> I don't actually think the CA is used in the deployment. We use certs from
> our CA everywhere, rather than from FreeIPA, so I believe if I turned this
> into a CA-less deployment it would be fine, but I haven't found clear
> documentation on how to do that. I'm ok with either removing the CA (and I
> have snapshots in case I need to revert), or with fixing the CA, but as it
> stands I can't do software update or add nodes to the cluster.
>
> What additional information can I provide? Thanks in advance,
AFAIK there is no supported way to go from a cafull installation to a
caless installation (there is the other way around).
Is the IPA CA available? I forget if `ipa-cacert-manage list` is
available in 4.9.6. If it is then you can check that way.
You can also see if the CA is working at all using commands provided by
the CA itself. Perhaps something like:
pki client init
pki ca cert find
The results don't matter much as long as it isn't an error. If you get a
list of certs then your CA can at least read its database. This is
basically what the cert-find healthcheck does but it tacks on
authentication as well.
rob
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue