[Freeipa-users] Common Name for the ipa-cacert-manage command

[Dmitri Pal]

On 04/30/2015 06:52 PM, William Graboyes wrote:
> I have to agree with Benjamen here.
>
> I guess it is time to get deep into API documentation.  This is a hell of a lot of hoops to jump through just so that users who don't have shell access can easily change their passwords without having to see a scare page.  Distributing the IPA CA is not an option at this point, as we have a very odd desktop support model.  I thought all of this was to be fixed in 4.1, which is why I went 4.1... and now nothing has changed... and I am back to square 1.

I am not sure I understand your expectations. There are really no other 
options.
You can go CA-less and have Puppet or similar to replace your certs when 
they expire.
You can use IPA CA and let certmonger do the work. IPA CA can be root or 
chained.
It is not clear what else we can do other than finish the automatic 
distribution of certs when key rotation happens.


> This is the only, and I am serious here, the only gating factor for FreeIPA going into production.  The self-signed certs on the UI.  It really isn't safe or secure to tell users to "Just trust the self signed cert."  You create an easy vector for users to get sucked into a phishing trap.
>
> Next question, Has anyone made or documented an external password change program for freeipa?
>
>
>
> On 4/30/15 3:28 PM, Benjamen Keroack wrote:
>> With respect, neither option is realistic in the common case. Unless I'm
>> mistaken, a CA-less installation will break in ~1 year when host
>> certificates expire and are not automatically renewed via certmonger.
>> Option 2 (sub-CA) is, as far as I can tell, also not feasible since no
>> public CA will sell subordinate CA certificates commercially. At least not
>> that I can find.
>>
>> In our case, the only option is to resign ourselves to using self-signed
>> certificates for the UI. End users can import IPA CA root cert if they
>> choose.
>>
>> On Thu, Apr 30, 2015 at 2:45 PM, Dmitri Pal <dpal at redhat.com> wrote:
>>
>>> On 04/30/2015 04:50 PM, William Graboyes wrote:
>>>
>>>> Let me ask this a different way.
>>>>
>>>> What is the easiest method of using a trusted third party cert for the
>>>> web UI?
>>>>
>>> Make IPA CA-less with just certs from that 3rd party CA installed or make
>>> IPA trust that CA and be a sub CA.
>>>
>>>
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-ca-options
>>>
>>>
>>>
>>>> Running IPA 4.1.0 on Centos 7.
>>>>
>>>> Thanks,
>>>> Bill
>>>> On 4/30/15 1:44 PM, Rob Crittenden wrote:
>>>>
>>>>> William Graboyes wrote:
>>>>>
>>>>>> Hi list,
>>>>>>
>>>>>> The end goal is to eliminate self signed certs from user interaction
>>>>>> with FreeIPA, without having to roll out changes to each user in the
>>>>>> house (and remote locations).  So basically changing the CA to a
>>>>>> trusted CA that will not bring "scare" the users with "Site security
>>>>>> cannot be verified, return to safety."
>>>>>>
>>>>>> The problem with the CN is that when it is read from the CSR the
>>>>>> CN="Certificate Authority".  Which is not an acceptable CN according
>>>>>> to the tool we use for generating certs, The tool we use expects a CN
>>>>>> of something along the lines of example.com.
>>>>>>
>>>>> That sounds odd. The CN of a CA doesn't represent a machine or a
>>>>> specific domain, it represents itself. Granted Certificate Authority
>>>>> isn't all that unique a name either, but it's what we defaulted to, IIRC
>>>>> based on the dogtag defaults.
>>>>>
>>>>> Changing it might have other odd side-effects too as it's hardcoded in a
>>>>> few other places. I'm not exactly sure what would break, if anything.
>>>>>
>>>>> It sounds like your tool is issuing a server cert, not a CA cert. A
>>>>> server cert traditionally has used cn=FQDN,<rest of subject>. That
>>>>> doesn't really apply to a CA.
>>>>>
>>>>> So it's changeable if you hack some installer code, but there be dragons.
>>>>>
>>>>> rob
>>>>>
>>>>>> Thanks,
>>>>>> Bill
>>>>>>
>>>>>> On 4/21/15 2:55 PM, Rob Crittenden wrote:
>>>>>>
>>>>>>> William Graboyes wrote:
>>>>>>>
>>>>>>>> Hi List,
>>>>>>>>
>>>>>>>> I am having yet another issue, when I run the following command:
>>>>>>>> ipa-cacert-manage renew --external-ca
>>>>>>>>
>>>>>>>> It does output the CSR, however the CN is not a valid name
>>>>>>>> (Certificate Authority).  Is it possible to change the output of
>>>>>>>> this command to use an external CA that requires a proper common
>>>>>>>> name to be in the CSR?
>>>>>>>>
>>>>>>>> What I am trying to do is change from the internal self signed
>>>>>>>> certs to an external CA signing system.
>>>>>>>>
>>>>>>>>   What isn't valid about the name?
>>>>>>> This would make the IPA CA a subordinate of the external CA. Is
>>>>>>> that what you want?
>>>>>>> rob
>>>>>>>
>>>>>>
>>>>>>
>>> --
>>> Thank you,
>>> Dmitri Pal
>>>
>>> Director of Engineering for IdM portfolio
>>> Red Hat, Inc.
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>>


-- 
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.