I know y'all have a lot of ignorant folks like me that you help with. I really
appreciate what you do. This is the first time in my life (32 yrs of *nix) I
have ever reached out to a mailing list for assistance, so apologies if I am
not aware of some etiquette and faux pas a bit.
Did that tell us anything useful? I don't really know what I am looking at,
there. I see that they all show as trusted. I do not know how to translate
those ipaKeyExtUsage fields.
I am getting pretty dizzy with this issue, now, after a week and two weekends
struggling through it. Hundreds of tabs open [no exaggeration] trying to
fasttrack myself to understanding what FreeIPA wants and how to give it. Seems
like the tools, directories, everything changes so much between versions that
it is so difficult to find the latest answers using the latest tools.
I have done too much to doc here. But, in every scenario ipa-certupdate
appears to be essential, and that step knocks out my changes. I have a couple
servers, now, sitting with certs given the proper Trust Attributes, and
everything seems to come up fine on them, if I never ipa-certupdate on them.
It persists reboot, even. That does not feel like they should be left this way.
The only way I have been able to get anything working is using the old certutil
tool, not using ipa-cert-manager . I just feel that I am ignorant about
something else ipa-cert-manage does that I am not doing. And/or, I have come
across a possible bug in ipa-cert-manage ? I cannot change Trust Attributes
nor delete certs with that tool.
Here is one way I have come up with to work around this (again, assuming
ipa-certupdate is never again executed on the server):
# ------------------
# Get list of cert names and attribute tags:
certutil -L -d /etc/ipa/nssdb;certutil -L -d
/etc/dirsrv/slapd-VSS-VZBI-COM;certutil -L -d /etc/pki/pki-tomcat/alias
# Modify the Trust Attributes field for each name in NSS
certutil -M -d /etc/ipa/nssdb -n "DigiCert Global G2 TLS RSA SHA256 2020 CA1 -
DigiCert Inc" -t C,, -f /etc/ipa/nssdb/pwdfile.txt
certutil -M -d /etc/ipa/nssdb -n "DigiCert Global Root G2 - DigiCert Inc" -t
C,, -f /etc/ipa/nssdb/pwdfile.txt
# Modify the Trust Attributes field for each name in dirsrv
certutil -M -d /etc/dirsrv/slapd-VSS-VZBI-COM/ -n "DigiCert Global G2 TLS RSA
SHA256 2020 CA1 - DigiCert Inc" -t C,, -f
/etc/dirsrv/slapd-VSS-VZBI-COM/pwdfile.txt
certutil -M -d /etc/dirsrv/slapd-VSS-VZBI-COM/ -n "DigiCert Global Root G2 -
DigiCert Inc" -t C,, -f /etc/dirsrv/slapd-VSS-VZBI-COM/pwdfile.txt
# Modify the Trust Attributes field for each name in pki-tomcat
certutil -M -d /etc/pki/pki-tomcat/alias -n "DigiCert Global G2 TLS RSA SHA256
2020 CA1 - DigiCert Inc" -t C,, -f /etc/pki/pki-tomcat/alias/pwdfile.txt
certutil -M -d /etc/pki/pki-tomcat/alias -n "DigiCert Global Root G2 - DigiCert
Inc" -t C,, -f /etc/pki/pki-tomcat/alias/pwdfile.txt
# ------------------
That is all after a complete reinstall on the server.
I have tried many other things, like -D deleting and -A adding them in manually
via certutil, but that has only gotten me into various forms of different
trouble.
On one server, I have this in all 3 databases:
DigiCertCAG2-root C,,
DigiCertCAG2-inter C,,
which seems great! Except, then I came across a great trick in another old
thread here on how to check validity, and:
certutil -V -u V -d /etc/dirsrv/slapd-VSS-VZBI-COM -n "DigiCertCAG2-root"
certutil: certificate is invalid: Certificate key usage inadequate for
attempted operation.
certutil -V -u V -d /etc/dirsrv/slapd-VSS-VZBI-COM -n "DigiCertCAG2-inter"
certutil: certificate is invalid: Certificate key usage inadequate for
attempted operation.
I don't understand what that means nor how to even begin searching for how to
continue down that path. It's the same CRT's I inserted all this time (I just
named them this time).
I am on my last day before the master expires. I am in trouble. I know my
emergency is not your emergency. Sorry if I sound as desperate/confused as I
am. (: But, I would really like to avoid a new thread asking how one goes
about migrating all data from a broken FIPA network into a newly built one.
--
_______________________________________________
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
