[Freeipa-users] Using our IPA CA as a trusted CA to sign ssl certificates

Fri Jun 3 16:00:54 UTC 2016

On 06/03/2016 11:02 AM, Rob Crittenden wrote:
> Bret Wortman wrote:
>> I'm not sure I'd call what we have "success" just yet. ;-)
>>
>> You're right -- F21, IPA 4.1.4-1. I'll try the steps you outlined and
>> see how we go.
>>
>> Rob, would you have just used the existing "localhost.key" instead of
>> generating a new one?
>
> No, I think you did the right thing, the default keysize was probably 
> still 1024 in F21. I double-checked the getcert-request man page and 
> it looks like it will use an existing key if one exists in the key 
> file passed in so I was wrong about that bit. You just didn't need to 
> use req to generate a CSR as certmonger will do that for you.
>
Good to know.

I tried the update-ca-trust on both the yum server and on my workstation 
but nothing changed even after an httpd restart. I did take a peek 
inside /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt and 
didn't see my /etc/ipa/ca.crt in there (which may not be a problem, but 
I confess I'm not sure what should be where at this point).

Bret

> rob
>
>>
>>
>> On 06/03/2016 09:48 AM, Rob Crittenden wrote:
>>> Bret Wortman wrote:
>>>> So for our internal yum server, I created a new key and cert 
>>>> request (it
>>>> had a localhost key and cert but I wanted to start clean):
>>>>
>>>>     # openssl genrsa 2048 > /etc/pki/tls/private/server.key
>>>>     # openssl req -new -x509 -nodes -sha1 -days 365 -key
>>>>     /etc/pki/tls/private/server.key > /etc/pki/tls/certs/server.crt
>>>>     # ipa-getcert request -f /etc/pki/tls/certs/server.crt -k
>>>>     /etc/pki/tls/private/server.key -r
>>>
>>> I try not to argue with success but I'd be curious what is actually
>>> going on here. You generate a CSR and call it a certificate. It is
>>> probably the case that certmonger is ignoring it altogether and
>>> generating its own CSR.
>>>
>>>> ipa-getcert list shows it approved. I set up SSL in apache to use the
>>>> above .key and .crt, but when I try to run yum against this using ssl:
>>>>
>>>>     # yum search ffmpeg
>>>>     Loaded plugins: langpacks
>>>> https://yum.private.net/fedora/releases/21/Everything/x86_64/os/repodata/repomd.xml: 
>>>>
>>>>
>>>>     [Errno 14] curl#60 - "Peer's certificate issuer has been marked as
>>>>     not trusted by the user."
>>>>     :
>>>>
>>>> Is there a step I need to take on the clients so they'll accept this
>>>> cert as trusted? I thought having it be signed by the IPA CA would 
>>>> have
>>>> taken care of that.
>>>>
>>>>     # ls -l /etc/ipa/ca.crt
>>>>     -rw-r--r-- 1 root root 2546 Apr 28  2014 /etc/ipa/ca.crt
>>>>     #
>>>
>>> Pretty much only IPA tools know to use this file.
>>>
>>> My knowledge is a bit stale on adding the IPA CA to the global trust
>>> but I'm pretty sure it is done automatically now and I think it was in
>>> the 4.2 timeframe. I'm assuming this is Fedora 21 so it doesn't have
>>> this code.
>>>
>>> Look at this,
>>> https://fedoraproject.org/wiki/Features/SharedSystemCertificates
>>>
>>> The idea is to add the IPA CA to that and then all tools using SSL
>>> would "just work".
>>>
>>> Something like:
>>>
>>> # cp /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
>>> # update-ca-trust
>>>
>>> You'd need to remember to manually undo this if you ever redo your IPA
>>> install (and get a new CA):
>>>
>>> # rm /etc/ipa/ca.crt /usr/share/pki/ca-trust-source/anchors/ipa-ca.pem
>>> # update-ca-trust
>>>
>>> Like I said, I'm pretty sure this is all automatic in some more recent
>>> versions of IPA.
>>>
>>> rob
>>>
>>>>
>>>> ---
>>>> Bret
>>>>
>>>> On 06/02/2016 07:25 PM, bret.wortman at damascusgrp.com wrote:
>>>>> Cool. I'll give this a go in the morning.
>>>>>
>>>>> Bret Wortman
>>>>> http://wrapbuddies.co/
>>>>>
>>>>> On Jun 2, 2016, 6:24 PM -0400, Fraser Tweedale <ftweedal at redhat.com>,
>>>>> wrote:
>>>>>> On Thu, Jun 02, 2016 at 05:35:01PM -0400,
>>>>>> bret.wortman at damascusgrp.com wrote:
>>>>>>> Sorry, let me back up a step. We need to implement hype
>>>>>>> everywhere. All our web services. And clients need to get
>>>>>>> keys&certs automatically whether through IPA or Puppet. These
>>>>>>> systems use IPA for everything but authentication (to keep most
>>>>>>> users off). I'm trying to wuss out the easiest way to make this
>>>>>>> happen smoothly.
>>>>>>>
>>>>>> Hi Bret,
>>>>>>
>>>>>> You can use the IPA CA to sign service certificates. See
>>>>>> http://www.freeipa.org/page/Certmonger#Request_a_new_certificate.
>>>>>>
>>>>>> IPA-enrolled machines already have the IPA certificate in their
>>>>>> trust store. If the clients are IPA-enrolled, everything should
>>>>>> Just Work, otherwise you can distribute the IPA CA certificate to
>>>>>> clients via Puppet** or whatever means you prefer.
>>>>>>
>>>>>> ** you will have to work out how, because I do not know Puppet :)
>>>>>>
>>>>>> Cheers,
>>>>>> Fraser
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jun 2, 2016, 5:31 PM -0400, Rob Crittenden<rcritten at redhat.com>,
>>>>>>> wrote:
>>>>>>>> Bret Wortman wrote:
>>>>>>>>> Is it possible to use our freeipa CA as a trusted CA to sign our
>>>>>>>>> internal SSL certificates? Our system runs on a private network
>>>>>>>>> and so
>>>>>>>>> using the usual trusted sources isn't an option. We've been using
>>>>>>>>> self-signed, but that adds some additional complications and we
>>>>>>>>> thought
>>>>>>>>> this might be a good solution.
>>>>>>>>>
>>>>>>>>> Is it possible, and, since most online guides defer to "submit
>>>>>>>>> the CSR
>>>>>>>>> to Verisign" or whomever, how would you go about producing one in
>>>>>>>>> this way?
>>>>>>>>
>>>>>>>> Not sure I understand the question. The IPA CA is also
>>>>>>>> self-signed. For
>>>>>>>> enrolled systems though at least the CA is pre-distributed so 
>>>>>>>> maybe
>>>>>>>> that
>>>>>>>> will help.
>>>>>>>>
>>>>>>>> rob
>>>>>>>>
>>>>>>
>>>>>>> -- 
>>>>>>> Manage your subscription for the Freeipa-users mailing list:
>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users
>>>>>>> Go to http://freeipa.org for more info on the project
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>