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 <[email protected]> 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* [email protected]
-- 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
