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

[Benjamen Keroack]

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
>



-- 
Benjamen Keroack
*Infrastructure/DevOps Engineer*
benjamen at dollarshaveclub.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150430/d59e99d3/attachment.htm>