Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users wrote:
Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
Looks like the browser is not using the system trust store. Please provide full details of operating system and package versions for both freeipa and browser packages.
Cheers, Fraser
Seems to happen on both Ubuntu 16.04 and 18.04.
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.6 LTS Release: 16.04 Codename: xenial
$ firefox --version Mozilla Firefox 67.0.4
freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed] freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic] firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64
Ubuntu 18.04 machine:
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic
freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed] freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all [installed,automatic] firefox/bionic-updates,bionic-security,now 69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed]
Where is the system trust store located? I was going to validate that the freeipa ca.crt is added to the system trust store. If its not there how do you add the ca.crt to the system trust store?
Should the ipa-install-client command add the system wide trust store?
I'll try this on CentOS tomorrow to see if its just an Ubuntu issue.
On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users wrote:
Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
Looks like the browser is not using the system trust store. Please provide full details of operating system and package versions for both freeipa and browser packages.
Cheers, Fraser
On Wed, Oct 09, 2019 at 08:58:14PM -0500, Kevin Vasko wrote:
Seems to happen on both Ubuntu 16.04 and 18.04.
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.6 LTS Release: 16.04 Codename: xenial
$ firefox --version Mozilla Firefox 67.0.4
freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed] freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic] firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64
Ubuntu 18.04 machine:
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic
freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed] freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all [installed,automatic] firefox/bionic-updates,bionic-security,now 69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed]
Where is the system trust store located? I was going to validate that the freeipa ca.crt is added to the system trust store. If its not there how do you add the ca.crt to the system trust store?
Should the ipa-install-client command add the system wide trust store?
Thanks for the details. I do not know about system trust on Ubuntu. It could be that ipa-client on Ubuntu does add the IPA CA to system trust, but the Firefox/Chrome packages ignore the system trust store.
Hopefully someone more familiar with Ubuntu can clarify.
Cheers, Fraser
I'll try this on CentOS tomorrow to see if its just an Ubuntu issue.
On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users wrote:
Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
Looks like the browser is not using the system trust store. Please provide full details of operating system and package versions for both freeipa and browser packages.
Cheers, Fraser
How would I validate that certs are getting added properly on a CentOS machine system wide store?
I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
-Kevin
On Oct 9, 2019, at 10:44 PM, Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Oct 09, 2019 at 08:58:14PM -0500, Kevin Vasko wrote:
Seems to happen on both Ubuntu 16.04 and 18.04.
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.6 LTS Release: 16.04 Codename: xenial
$ firefox --version Mozilla Firefox 67.0.4
freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed] freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic] firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64
Ubuntu 18.04 machine:
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic
freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed] freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all [installed,automatic] firefox/bionic-updates,bionic-security,now 69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed]
Where is the system trust store located? I was going to validate that the freeipa ca.crt is added to the system trust store. If its not there how do you add the ca.crt to the system trust store?
Should the ipa-install-client command add the system wide trust store?
Thanks for the details. I do not know about system trust on Ubuntu. It could be that ipa-client on Ubuntu does add the IPA CA to system trust, but the Firefox/Chrome packages ignore the system trust store.
Hopefully someone more familiar with Ubuntu can clarify.
Cheers, Fraser
I'll try this on CentOS tomorrow to see if its just an Ubuntu issue.
On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users wrote:
Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
Looks like the browser is not using the system trust store. Please provide full details of operating system and package versions for both freeipa and browser packages.
Cheers, Fraser
Kevin Vasko via FreeIPA-users wrote:
How would I validate that certs are getting added properly on a CentOS machine system wide store?
I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like:
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates
rob
-Kevin
On Oct 9, 2019, at 10:44 PM, Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Oct 09, 2019 at 08:58:14PM -0500, Kevin Vasko wrote:
Seems to happen on both Ubuntu 16.04 and 18.04.
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.6 LTS Release: 16.04 Codename: xenial
$ firefox --version Mozilla Firefox 67.0.4
freeipa-client/xenial,now 4.3.1-0ubuntu1 amd64 [installed] freeipa-common/xenial,xenial,now 4.3.1-0ubuntu1 all [installed,automatic] firefox/now 67.0.4+build1-0ubuntu0.16.04.1 amd64
Ubuntu 18.04 machine:
$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic
freeipa-client/bionic,now 4.7.0~pre1+git20180411-2ubuntu2 amd64 [installed] freeipa-common/bionic,bionic,now 4.7.0~pre1+git20180411-2ubuntu2 all [installed,automatic] firefox/bionic-updates,bionic-security,now 69.0.2+build1-0ubuntu0.18.04.1 amd64 [installed]
Where is the system trust store located? I was going to validate that the freeipa ca.crt is added to the system trust store. If its not there how do you add the ca.crt to the system trust store?
Should the ipa-install-client command add the system wide trust store?
Thanks for the details. I do not know about system trust on Ubuntu. It could be that ipa-client on Ubuntu does add the IPA CA to system trust, but the Firefox/Chrome packages ignore the system trust store.
Hopefully someone more familiar with Ubuntu can clarify.
Cheers, Fraser
I'll try this on CentOS tomorrow to see if its just an Ubuntu issue.
On Wed, Oct 9, 2019 at 8:25 PM Fraser Tweedale ftweedal@redhat.com wrote:
On Wed, Oct 09, 2019 at 06:28:11PM -0500, Kevin Vasko via FreeIPA-users wrote:
Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
Looks like the browser is not using the system trust store. Please provide full details of operating system and package versions for both freeipa and browser packages.
Cheers, Fraser
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.fedorahoste...
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
Kevin Vasko via FreeIPA-users wrote:
How would I validate that certs are getting added properly on a CentOS machine system wide store?
I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like:
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates
This is already done by ipa-client-install
Kees Bakker,
If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly.
-Kevin
On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
Kevin Vasko via FreeIPA-users wrote:
How would I validate that certs are getting added properly on a CentOS machine system wide store?
I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like:
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates
This is already done by ipa-client-install _______________________________________________ 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.fedorahoste...
Kevin Vasko via FreeIPA-users wrote:
Kees Bakker,
If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly.
Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution.
rob
-Kevin
On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
Kevin Vasko via FreeIPA-users wrote:
How would I validate that certs are getting added properly on a CentOS machine system wide store?
I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like:
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates
This is already done by ipa-client-install _______________________________________________ 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.fedorahoste...
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.fedorahoste...
I actually manually checked the system wide crt files on each distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my /etc/ipa/ca.crt did appear to be in the each of their respective *.crt files. That indicates to me that there isn't any problem with the ipa-install-client on any of the distributions like I originally thought. Rob it does look like Ubuntu is adding it to the /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I didn't do it manually on any of my systems, so it does appear they are doing it somehow.
These are the locations I checked.
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc. "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
What appears to be the problem is (unless I'm mistaken) Firefox nor Chrome are using the system wide cert locations apparently and only using their own cert store. At least according to this article: https://thomas-leister.de/en/how-to-import-ca-root-certificate/
It kind of is backed up by this article on the Mozilla page. https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
So based off of this information I'm going to have to manually add the root certificates to each Chrome and Firefox cert store on the client machines, which is a bummer.
Sorry for the noise.
On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden rcritten@redhat.com wrote:
Kevin Vasko via FreeIPA-users wrote:
Kees Bakker,
If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly.
Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution.
rob
-Kevin
On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
Kevin Vasko via FreeIPA-users wrote:
How would I validate that certs are getting added properly on a CentOS machine system wide store?
I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like:
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates
This is already done by ipa-client-install _______________________________________________ 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.fedorahoste...
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.fedorahoste...
On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
I actually manually checked the system wide crt files on each distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my /etc/ipa/ca.crt did appear to be in the each of their respective *.crt files. That indicates to me that there isn't any problem with the ipa-install-client on any of the distributions like I originally thought. Rob it does look like Ubuntu is adding it to the /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I didn't do it manually on any of my systems, so it does appear they are doing it somehow.
These are the locations I checked.
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc. "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
What appears to be the problem is (unless I'm mistaken) Firefox nor Chrome are using the system wide cert locations apparently and only using their own cert store. At least according to this article: https://thomas-leister.de/en/how-to-import-ca-root-certificate/
On RHEL/Fedora/CentOS we import system wide cert store automatically to NSS databases through p11-kit.
On Ubuntu/Debian/Gentoo you need to do that manually.
It kind of is backed up by this article on the Mozilla page. https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
So based off of this information I'm going to have to manually add the root certificates to each Chrome and Firefox cert store on the client machines, which is a bummer.
Sorry for the noise.
On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden rcritten@redhat.com wrote:
Kevin Vasko via FreeIPA-users wrote:
Kees Bakker,
If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly.
Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution.
rob
-Kevin
On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
Kevin Vasko via FreeIPA-users wrote:
How would I validate that certs are getting added properly on a CentOS machine system wide store?
I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like:
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates
This is already done by ipa-client-install _______________________________________________ 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.fedorahoste...
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.fedorahoste...
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.fedorahoste...
Alexander,
Unless I'm misunderstanding the information I don't think it will matter though because Firefox and Chrome use their own certificates stores. I found that information after I posted this question. Speaking specifically for firefox (and Chrome looks to be similar)...I'm concluding that why I'm not seeing it work is because of this...
"Since Firefox does not use the operating system's certificate store by default, these CA certificates must be added in to Firefox using one of the following methods. " taken from here https://wiki.mozilla.org/CA/AddRootToFirefox
So I at this point I don't think anything is wrong with ipa-install-client and it is performing correctly at this point adding it to the cert store. Given that the exception that you mentioned, that there is a difference in ipa-install-client adding it to the the NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian variants. However, I still don't think that will matter since Firefox/Chrome aren't reading either the NSS database or the crt bundle from what I understand.
I'm going to keep digging to see if I find a solution for getting FF/Chrome to look at my certs and will post back on what I find.
-Kevin
On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
I actually manually checked the system wide crt files on each distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my /etc/ipa/ca.crt did appear to be in the each of their respective *.crt files. That indicates to me that there isn't any problem with the ipa-install-client on any of the distributions like I originally thought. Rob it does look like Ubuntu is adding it to the /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I didn't do it manually on any of my systems, so it does appear they are doing it somehow.
These are the locations I checked.
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc. "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
What appears to be the problem is (unless I'm mistaken) Firefox nor Chrome are using the system wide cert locations apparently and only using their own cert store. At least according to this article: https://thomas-leister.de/en/how-to-import-ca-root-certificate/
On RHEL/Fedora/CentOS we import system wide cert store automatically to NSS databases through p11-kit.
On Ubuntu/Debian/Gentoo you need to do that manually.
It kind of is backed up by this article on the Mozilla page. https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
So based off of this information I'm going to have to manually add the root certificates to each Chrome and Firefox cert store on the client machines, which is a bummer.
Sorry for the noise.
On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden rcritten@redhat.com wrote:
Kevin Vasko via FreeIPA-users wrote:
Kees Bakker,
If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly.
Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution.
rob
-Kevin
On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
Kevin Vasko via FreeIPA-users wrote: > How would I validate that certs are getting added properly on a CentOS machine system wide store? > > I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS. On Fedora the chain is put into /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
There is no Debian/Ubuntu equivalent in the upstream source (it's possible it is done in packaging). You could try something like:
cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt update-ca-certificates
This is already done by ipa-client-install _______________________________________________ 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.fedorahoste...
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.fedorahoste...
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.fedorahoste...
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
On to, 10 loka 2019, Kevin Vasko wrote:
Alexander,
Unless I'm misunderstanding the information I don't think it will matter though because Firefox and Chrome use their own certificates stores. I found that information after I posted this question. Speaking specifically for firefox (and Chrome looks to be similar)...I'm concluding that why I'm not seeing it work is because of this...
"Since Firefox does not use the operating system's certificate store by default, these CA certificates must be added in to Firefox using one of the following methods. " taken from here https://wiki.mozilla.org/CA/AddRootToFirefox
On RHEL/Fedora we do have some magic: https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules
On my Fedora 30 system I have this for my Firefox profile:
$ modutil -dbdir sql:/home/abokovoy/.mozilla/firefox/$profile/ -list
Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46 slots: 2 slots attached status: loaded
slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
2. mPollux library name: /usr/lib64/libcryptoki.so uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1 slots: There are no slots attached to this module status: loaded
3. p11-kit-proxy library name: p11-kit-proxy.so uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 slots: There are no slots attached to this module status: loaded -----------------------------------------------------------
As you can see, there are three tokens attached. Number 1 is the NSS internal 'token', that's how NSS database looks like typically. Number 2 is a crypto token inserted by the Fujitsu Finland Oy which is used for my governmental ID operations through Firefox. Number three is the proxy for system-wide crypto tokens in Fedora.
If I query that token separately, I can see a lot of certificates inside Firefox NSS database. If I omit -h option, certificates from all tokens get listed.
$ certutil -d sql:/home/abokovoy/.mozilla/firefox/$profile/ -h p11-kit-proxy -L |wc -l 249
Exactly same story is with Chrome/Chromium, only that they use different store than Firefox:
$ modutil -dbdir sql:/home/abokovoy/.pki/nssdb -list
Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46 slots: 2 slots attached status: loaded
slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
2. DigiSign PKCS#11 Module library name: /usr/lib64/libcryptoki.so uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1 slots: There are no slots attached to this module status: loaded
3. p11-kit-proxy library name: p11-kit-proxy.so uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 slots: There are no slots attached to this module status: loaded -----------------------------------------------------------
In past, people did manual work to pick up all the certs like https://blog.xelnor.net/firefox-systemcerts/ but it is not really needed anymore if you have p11-kit-proxy on your system. By default p11-kit-proxy has two modules:
$ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized token: Default Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized opensc: opensc-pkcs11.so library-description: OpenSC smartcard framework library-manufacturer: OpenSC Project library-version: 0.19
It is the first one that brings all the system-wide certificates into NSS and other databases. For OpenSSL applications it can be brought in via PKCS#11 engine support.
So I at this point I don't think anything is wrong with ipa-install-client and it is performing correctly at this point adding it to the cert store. Given that the exception that you mentioned, that there is a difference in ipa-install-client adding it to the the NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian variants. However, I still don't think that will matter since Firefox/Chrome aren't reading either the NSS database or the crt bundle from what I understand.
I'm going to keep digging to see if I find a solution for getting FF/Chrome to look at my certs and will post back on what I find.
-Kevin
On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
I actually manually checked the system wide crt files on each distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my /etc/ipa/ca.crt did appear to be in the each of their respective *.crt files. That indicates to me that there isn't any problem with the ipa-install-client on any of the distributions like I originally thought. Rob it does look like Ubuntu is adding it to the /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I didn't do it manually on any of my systems, so it does appear they are doing it somehow.
These are the locations I checked.
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc. "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
What appears to be the problem is (unless I'm mistaken) Firefox nor Chrome are using the system wide cert locations apparently and only using their own cert store. At least according to this article: https://thomas-leister.de/en/how-to-import-ca-root-certificate/
On RHEL/Fedora/CentOS we import system wide cert store automatically to NSS databases through p11-kit.
On Ubuntu/Debian/Gentoo you need to do that manually.
It kind of is backed up by this article on the Mozilla page. https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
So based off of this information I'm going to have to manually add the root certificates to each Chrome and Firefox cert store on the client machines, which is a bummer.
Sorry for the noise.
On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden rcritten@redhat.com wrote:
Kevin Vasko via FreeIPA-users wrote:
Kees Bakker,
If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly.
Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution.
rob
-Kevin
On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote > > Kevin Vasko via FreeIPA-users wrote: >> How would I validate that certs are getting added properly on a CentOS machine system wide store? >> >> I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS. > On Fedora the chain is put into > /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed. > > There is no Debian/Ubuntu equivalent in the upstream source (it's > possible it is done in packaging). You could try something like: > > cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt > update-ca-certificates This is already done by ipa-client-install _______________________________________________ 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.fedorahoste...
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.fedorahoste...
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.fedorahoste...
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
So you are saying that if the p11-kit-trust module is available it should be automatically adding the system wide trust store into the internal Firefox cert store?
This is the out of my commands. I have the cert store thats create in my home directory.
But there is no p11-kit-proxy do I have to add that myself? If so how do I do that?
modutil -dbdir sql:/home/<username>/.mozilla/firefox/9zd63dro.default-release/ -list
Listing of PKCS #11 Modules ----------------------------------------------------------- 1. NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.35 slots: 2 slots attached status: loaded
slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS User Private Key and Certificate Services token: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203 -----------------------------------------------------------
I have the p11-kit-trust module.
$ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized
On Thu, Oct 10, 2019 at 11:09 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 10 loka 2019, Kevin Vasko wrote:
Alexander,
Unless I'm misunderstanding the information I don't think it will matter though because Firefox and Chrome use their own certificates stores. I found that information after I posted this question. Speaking specifically for firefox (and Chrome looks to be similar)...I'm concluding that why I'm not seeing it work is because of this...
"Since Firefox does not use the operating system's certificate store by default, these CA certificates must be added in to Firefox using one of the following methods. " taken from here https://wiki.mozilla.org/CA/AddRootToFirefox
On RHEL/Fedora we do have some magic: https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules
On my Fedora 30 system I have this for my Firefox profile:
$ modutil -dbdir sql:/home/abokovoy/.mozilla/firefox/$profile/ -list
Listing of PKCS #11 Modules
NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46 slots: 2 slots attached status: loaded
slot: NSS Internal Cryptographic Servicestoken: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS User Private Key and Certificate Servicestoken: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
mPollux library name: /usr/lib64/libcryptoki.so uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1 slots: There are no slots attached to this module status: loaded
p11-kit-proxy library name: p11-kit-proxy.so uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 slots: There are no slots attached to this module status: loaded
As you can see, there are three tokens attached. Number 1 is the NSS internal 'token', that's how NSS database looks like typically. Number 2 is a crypto token inserted by the Fujitsu Finland Oy which is used for my governmental ID operations through Firefox. Number three is the proxy for system-wide crypto tokens in Fedora.
If I query that token separately, I can see a lot of certificates inside Firefox NSS database. If I omit -h option, certificates from all tokens get listed.
$ certutil -d sql:/home/abokovoy/.mozilla/firefox/$profile/ -h p11-kit-proxy -L |wc -l 249
Exactly same story is with Chrome/Chromium, only that they use different store than Firefox:
$ modutil -dbdir sql:/home/abokovoy/.pki/nssdb -list
Listing of PKCS #11 Modules
NSS Internal PKCS #11 Module uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46 slots: 2 slots attached status: loaded
slot: NSS Internal Cryptographic Servicestoken: NSS Generic Crypto Services uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS User Private Key and Certificate Servicestoken: NSS Certificate DB uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
DigiSign PKCS#11 Module library name: /usr/lib64/libcryptoki.so uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1 slots: There are no slots attached to this module status: loaded
p11-kit-proxy library name: p11-kit-proxy.so uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1 slots: There are no slots attached to this module status: loaded
In past, people did manual work to pick up all the certs like https://blog.xelnor.net/firefox-systemcerts/ but it is not really needed anymore if you have p11-kit-proxy on your system. By default p11-kit-proxy has two modules:
$ p11-kit list-modules p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized token: Default Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized opensc: opensc-pkcs11.so library-description: OpenSC smartcard framework library-manufacturer: OpenSC Project library-version: 0.19
It is the first one that brings all the system-wide certificates into NSS and other databases. For OpenSSL applications it can be brought in via PKCS#11 engine support.
So I at this point I don't think anything is wrong with ipa-install-client and it is performing correctly at this point adding it to the cert store. Given that the exception that you mentioned, that there is a difference in ipa-install-client adding it to the the NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian variants. However, I still don't think that will matter since Firefox/Chrome aren't reading either the NSS database or the crt bundle from what I understand.
I'm going to keep digging to see if I find a solution for getting FF/Chrome to look at my certs and will post back on what I find.
-Kevin
On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy abokovoy@redhat.com wrote:
On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
I actually manually checked the system wide crt files on each distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my /etc/ipa/ca.crt did appear to be in the each of their respective *.crt files. That indicates to me that there isn't any problem with the ipa-install-client on any of the distributions like I originally thought. Rob it does look like Ubuntu is adding it to the /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I didn't do it manually on any of my systems, so it does appear they are doing it somehow.
These are the locations I checked.
"/etc/ssl/certs/ca-certificates.crt", // Debian/Ubuntu/Gentoo etc. "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6 "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
What appears to be the problem is (unless I'm mistaken) Firefox nor Chrome are using the system wide cert locations apparently and only using their own cert store. At least according to this article: https://thomas-leister.de/en/how-to-import-ca-root-certificate/
On RHEL/Fedora/CentOS we import system wide cert store automatically to NSS databases through p11-kit.
On Ubuntu/Debian/Gentoo you need to do that manually.
It kind of is backed up by this article on the Mozilla page. https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
So based off of this information I'm going to have to manually add the root certificates to each Chrome and Firefox cert store on the client machines, which is a bummer.
Sorry for the noise.
On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden rcritten@redhat.com wrote:
Kevin Vasko via FreeIPA-users wrote:
Kees Bakker,
If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu 18.04 and based on Rob's comment it might not be done if I'm understanding him correctly.
Assuming I'm reading the code right it is not being executed on Debian/Ubuntu. At least not in the source. It's possible it is patched into the package in the distribution.
rob
-Kevin
On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote: > > On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote >> >> Kevin Vasko via FreeIPA-users wrote: >>> How would I validate that certs are getting added properly on a CentOS machine system wide store? >>> >>> I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS. >> On Fedora the chain is put into >> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed. >> >> There is no Debian/Ubuntu equivalent in the upstream source (it's >> possible it is done in packaging). You could try something like: >> >> cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt >> update-ca-certificates > This is already done by ipa-client-install > _______________________________________________ > 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.fedorahoste... _______________________________________________ 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.fedorahoste...
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.fedorahoste...
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland
This article explains how Firefox and the OS certificate database are related. Starting with Firefox 64, an enterprise policy controls the relationship between Firefox trusted roots and OS trusted roots.
https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Fraser Tweedale -
Kees Bakker -
Kevin Vasko -
Nick DeMarco -
Rob Crittenden