Hopefully I'm just missing something face-palm level obvious, but I am running into some trouble when interfacing with my CA functionality on an IPA server cluster. My attempts at scouring all my saved prior-comms from the mailing-list as well as several search-engines are not enchanting me with much clue.
It appears that my need for the LetsEncrypt certs for the user-facing Web-UI and LDAPs components are causing IPA to dis-trust itself.
4-node cluster - Ubuntu19.10
(all nodes currently fully updated/patched via the official Ubuntu repos)
VERSION: 4.8.1, API_VERSION: 2.233
running letsencrypt certificates successfully for HTTPs & LDAPs connectivity
These 4-nodes are all happily running and replicating betwixt each other. LDAPs is functioning great and many linux systems are able to all join as freeipa-clients. Users and groups are replicating and being used elegantly for many LDAP-based authentication/authorization needs.
Overall, for these nodes, life is good.
Where I'm running into trouble is in finally wanting to leverage certificate issuance on a per-user basis. End goal is integrating things like yubikeys, user-cert auth, and so on.
In the UI, when I enter a user's account and select Actions->New Certificate, I am able to successfully issue the couple prompted 'certutil' commands to generate the user's CSR. I then paste in the contents of the CSR and hit 'Issue' and run into the following error:
IPA Error 907: NetworkErrorcannot connect to 'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login': [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)
As I then start digging into cli-mode to attempt to understand where things are unhappy, I run into similar troubles with the server attempting to talk to itself and not being very happy about it.
chris@REDACTED-1:~$ ipa ca-find
1 CA matched
Description: IPA CA
Authority ID: 8acca54b-64d7-44bf-b8f7-59316213cfb6
Subject DN: CN=Certificate Authority,O=IPA.REDACTED.COM
Issuer DN: CN=Certificate Authority,O=IPA.REDACTED.COM
Number of entries returned 1
chris@REDACTED-1:~$ ipa ca-show
ipa: ERROR: cannot connect to 'https://REDACTED-1.ipa.REDACTED.com:443/ca/rest/account/login': [SSL: TLSV1_ALERT_UNKNOWN_CA] tlsv1 alert unknown ca (_ssl.c:2508)
Verifying with 'openssl s_client' returns the valid and non-expired LE cert-chain.
chris@REDACTED-1:~$ openssl s_client REDACTED-1.ipa.REDACTED.com:443
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
depth=1 C = US, O = Let's Encrypt, CN = R3
depth=0 CN = REDACTED-1.ipa.REDACTED.com
0 s:CN = REDACTED-1.ipa.REDACTED.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
SSL handshake has read 3046 bytes and written 413 bytes
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
Can anyone please hit me with some clue-bat as to where I can read to understand how to get IPA to love itself? I'm suspecting it's likely some certificate inclusion/exception that I need to add so that API calls and the ipa command itself will actually respect the LE cert-chain?
Any hints would be greatly appreciated.
-- Node-Nine, Inc. firstname.lastname@example.org 619.354.6463
FreeIPA-users mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.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://email@example.com
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure