On Fri, Nov 1, 2019, at 8:50 AM, Sumit Bose wrote:
On Fri, Oct 25, 2019 at 08:27:33PM -0400, James Cassell wrote:
>
> On Fri, Oct 25, 2019, at 4:41 PM, James Ralston wrote:
> > On Mon, Oct 21, 2019 at 4:25 PM James Cassell
> > <fedoraproject(a)cyberpear.com> wrote:
> > > I'm in a similar situation... hoping to not write my own nssdb
> > > ansible role, but I'll probably need to write one since I didn't
see
> > > a good existing one.
> >
> > I figured out a way to avoid needing to maintain certificates in
> > /etc/pki/nssdb. You only need to do these two things:
> >
> > $ pkcs11-switch opensc
> > $ ln -s /usr/lib64/libnssckbi.so /etc/pki/nssdb/
> >
> > As long as alternatives is using p11-kit-trust.so:
> >
> > $ alternatives --display libnssckbi.so.x86_64
> > libnssckbi.so.x86_64 - status is auto.
> > link currently points to /usr/lib64/pkcs11/p11-kit-trust.so
> > /usr/lib64/pkcs11/p11-kit-trust.so - priority 30
> > /usr/lib64/nss/libnssckbi.so - priority 10
> > Current `best' version is /usr/lib64/pkcs11/p11-kit-trust.so.
> >
> > …then p11-kit-trust.so will automatically shim the certificate trust
> > database maintained by update-ca-trust(8) into NSSDB.
> >
>
> Awesome, that sounds like a huge time saver! I'm going to try that next week.
I tried it out, and it works pretty well. I ended up doing it with `modutil` instead of
creating a symlink so that it could be deleted by modutil if it were to become necessary:
# modutil -dbdir /etc/pki/nssdb/ -add 'Root Certs' -libfile
/usr/lib64/libnssckbi.so
(see below for disabling the "Default Trust" certificates an leaving only the
"System Trust" certs.)
Hi,
while this might be a time saver and helps to store the same CA
certificate into various different places I'd like to add a word of
caution here.
Thanks for the push to make it more secure!
When using certificate mapping and matching rules anyone can create
a
certificate which matches the rules and matches to any given user. This
means only the CA signature can assure that is really issued by the
expected CA. The system-wide CA database will contain a wide range of CA
certificates mostly to make sure that web-browsing with https works
without much issue. Many of the CA from the system-wide database have
strict procedures and policies to make sure only properly justified
certificates are issued. But you should consider if you would really
trust all those CAs to not issue a fake sub-CA certificate which then ca
be used to create a certificate with allows authentication to your
system.
You can only add the system-customized certificates (aka "System Trust") to the
nssdb by disabling the "Default Trust" store:
# modutil -dbdir /etc/pki/nssdb/ -disable 'Root Certs' -slot
/usr/share/pki/ca-trust-source
You can then verify that only your custom Root Certs are trusted:
# certutil -L -d /etc/pki/nssdb/ -h all
Please note this is only important if not the full certificate is
used
for mapping to the user. Since the full certificate contains the key and
the signature of the CA it cannot be faked. Only if you use single
components from the certificate like e.g. a stored Kerberos principal,
you should take care of the list of trusted CAs.
In effect, with SSSD-AD connection on RHEL 7, it doesn't matter since you need the
userCertificate attribute and always match the full cert. (I've opened a Support Case
to request the certmap backport to RHEL 7, per this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1736845 )
V/r,
James Cassell