Apologies for the belated response - took
me a bit to verify across all clients.
When I installed the LE certs on each replica/server, I
performed the following:
=====(the privkey & fullchain files provided by LE)=====
ipa-server-certinstall -w -d privkey.pem fullchain.pem
&
/usr/sbin/ipa-certupdate
=====
I have verified via 'openssl s_client -connect' that both https
& ldaps are serving the proper LE certificates across all
IPA servers.
I have also now iterated across every ipa-client installation
and run 'ipa-certupdate' as well. All the
/etc/ssl/certs/ca-certificates.crt files on each and every
system have the LE certs and are current.
Unfortunately, the 'Actions->New Certificate' process I
mentioned is still giving me identical behavior.
I followed the exact steps in the NewCert dialogue from one of
the validated-current ipa-clients:
=====
Create a certificate database or use an existing one. To
create a new database:
# certutil -N -d <database path>
Create a CSR with subject CN=<uid>,O=<realm>,
for example:
# certutil -R -d <database path> -a -g <key
size> -s 'CN=chris,O=IPA.REDACTED.COM'
=====
-Chris
On 6/12/21 3:55 AM, Florence Renaud
wrote:
Hi,
when the let's encrypt
certificates were installed, did you run ipa-cacert-manage
install on one of the nodes + ipa-certupdate on all the
IPA machines? It's important to run ipa-certupdate on
all the server/replicas/clients in order to install the CA
everywhere.
flo
Hello
folks.
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)
===
ipa --version
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: NetworkError
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
------------
Name: ipa
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
Name: ipa
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
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST
Root
CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = REDACTED-1.ipa.REDACTED.com
verify return:1
---
Certificate chain
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
---
...<output-truncated>...
---
SSL handshake has read 3046 bytes and written 413
bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
...<output-truncated>...
==========
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.
Thanks,
-Chris
--
REDACTED, Inc.
chris@REDACTED.com
619.354.6463
_______________________________________________
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.fedorahosted.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
REDACTED, Inc.
chris@REDACTED.com
619.354.6463
_______________________________________________
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.fedorahosted.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure