<div dir="ltr">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.<div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 30, 2015 at 2:45 PM, Dmitri Pal <span dir="ltr"><<a href="mailto:dpal@redhat.com" target="_blank">dpal@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 04/30/2015 04:50 PM, William Graboyes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let me ask this a different way.<br>
<br>
What is the easiest method of using a trusted third party cert for the web UI?<br>
</blockquote>
<br></span>
Make IPA CA-less with just certs from that 3rd party CA installed or make IPA trust that CA and be a sub CA.<br>
<br>
<a href="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" target="_blank">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</a><div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Running IPA 4.1.0 on Centos 7.<br>
<br>
Thanks,<br>
Bill<br>
On 4/30/15 1:44 PM, Rob Crittenden wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
William Graboyes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi list,<br>
<br>
The end goal is to eliminate self signed certs from user interaction<br>
with FreeIPA, without having to roll out changes to each user in the<br>
house (and remote locations).  So basically changing the CA to a<br>
trusted CA that will not bring "scare" the users with "Site security<br>
cannot be verified, return to safety."<br>
<br>
The problem with the CN is that when it is read from the CSR the<br>
CN="Certificate Authority".  Which is not an acceptable CN according<br>
to the tool we use for generating certs, The tool we use expects a CN<br>
of something along the lines of <a href="http://example.com" target="_blank">example.com</a>.<br>
</blockquote>
That sounds odd. The CN of a CA doesn't represent a machine or a<br>
specific domain, it represents itself. Granted Certificate Authority<br>
isn't all that unique a name either, but it's what we defaulted to, IIRC<br>
based on the dogtag defaults.<br>
<br>
Changing it might have other odd side-effects too as it's hardcoded in a<br>
few other places. I'm not exactly sure what would break, if anything.<br>
<br>
It sounds like your tool is issuing a server cert, not a CA cert. A<br>
server cert traditionally has used cn=FQDN,<rest of subject>. That<br>
doesn't really apply to a CA.<br>
<br>
So it's changeable if you hack some installer code, but there be dragons.<br>
<br>
rob<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Bill<br>
<br>
On 4/21/15 2:55 PM, Rob Crittenden wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
William Graboyes wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi List,<br>
<br>
I am having yet another issue, when I run the following command:<br>
ipa-cacert-manage renew --external-ca<br>
<br>
It does output the CSR, however the CN is not a valid name<br>
(Certificate Authority).  Is it possible to change the output of<br>
this command to use an external CA that requires a proper common<br>
name to be in the CSR?<br>
<br>
What I am trying to do is change from the internal self signed<br>
certs to an external CA signing system.<br>
<br>
</blockquote>
What isn't valid about the name?<br>
This would make the IPA CA a subordinate of the external CA. Is<br>
that what you want?<br>
rob<br>
</blockquote>
<br>
<br>
</blockquote></blockquote></blockquote>
<br>
<br>
-- <br></div></div>
Thank you,<br>
Dmitri Pal<br>
<br>
Director of Engineering for IdM portfolio<br>
Red Hat, Inc.<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Manage your subscription for the Freeipa-users mailing list:<br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
Go to <a href="http://freeipa.org" target="_blank">http://freeipa.org</a> for more info on the project<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Benjamen Keroack</div><div><i>Infrastructure/DevOps Engineer</i></div><div><a href="mailto:benjamen@dollarshaveclub.com" target="_blank">benjamen@dollarshaveclub.com</a></div><div><br></div></div></div></div></div>
</div>