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 <d...@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.
--
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
