On Tue, Mar 13, 2018 at 9:07 PM, Fraser Tweedale <ftweedal(a)redhat.com>
wrote:
On Tue, Mar 13, 2018 at 07:41:32PM -0500, Jonathan Vaughn via
FreeIPA-users wrote:
> Looking at migrating from a hodgepodge of 389 DS, kerberos-ldap, and
custom
> built things that manage our PKI and so on, to FreeIPA (which looks like
it
> can probably cover all our needs), and had a couple of SSL related
> questions.
>
> 1) It looks like improvements are proposed for being able to generate
> certificates from the web UI :
>
https://www.freeipa.org/page/V4/Automatic_Certificate_
Request_Generation#FreeIPA_Web_UI
>
> Does anyone know the status of such plans? I see some work was done over
> the past year but I haven't been able to find anything obviously related
to
> adding such ability to the web UI. Having to use the command line tools
is
> not the end of the world, but being able to do it from the web UI would
> make things easier sometimes ... I tried installing the latest release
in a
> Fedora VM but didn't see any way to generate the CSR itself from the Web
UI.
>
On hold. It would not help much in your use case anyway; it is
useful for browser enrolment but for non-browser use cases like
OpenVPN the key will have to extracted from the browser, and CLI
tools used to prepare the key and certificate for use with OpenVPN.
It would still be useful to me, though as you point out not so much for
OpenVPN. We also would use it for whenever some internal site needs to be
spun up and someone needs a SSL certificate for it. If it's externally
accessible we just use Let's Encrypt, but for sites that are only
accessible via internal DNS that doesn't work. It's not any kind of "deal
breaker", it just would be nice to have. Copying the certificates
themselves around isn't the hard to do, it's just nice to be able generate
the CSR in the browser instead of using CLI.
> 2) What is the correct / recommended way to issue certificates to users
for
> use with OpenVPN? We would have both site to site VPNs which I assume
would
> be issued similar to a regular service/web server SSL certificate, as
well
> as certificates for individual users. Do we add the users
> laptops/workstations as hosts in FreeIPA and then issue regular certs for
> them that way, or is there a way to issue a cert for a user and tie it to
> their identity (versus their laptop/workstation 's identity) ? Also, is
> there a specific certificate 'profile' that should be used?
>
The steps are::
# 1. export caIPAserviceCert configuration
ipa certprofile-show --out openvpn-client.cfg caIPAserviceCert
# 2. edit the profile configuration. remove `1.3.6.1.5.5.7.3.1'
# from the exKeyUsageOIDs config. Change the profile name
# to (for example) openvpn_client
$EDITOR openvpn-client.cfg
# 3. import the new profile
ipa certprofile-import openvpn-client --file openvpn-client.cfg \
--store=1 --desc="OpenVPN client certificates"
# 4 (optional) create a sub-CA for openvpn authentication.
# Set the subject name to whatever you actually want.
ipa ca-add openvpn --subject 'CN=OpenVPN CA, O=YOUR.DOMAIN'
# 5. Add a CA ACL to allow issuance of certificates to users using
# the new profile and a particular CA
ipa caacl-add users_openvpn --usercat=all
ipa caacl-add-profile --certprofile openvpn_client
ipa caacl-add-ca users_openvpn --ca openvpn
For caacl-add-ca use `--ca ipa' if you didn't add an
OpenVPN-specific CA at step 4.
Then you can issue OpenVPN client certificates to users. Configure
OpenVPN to trust the issuer certificate and you're good to go.
HTH,
Fraser
Thanks for that, I don't think I would have figured that out on my own!
When you say "Then you can issue OpenVPN client certficiates to users", is
there anything specific we need to do so that the SSL certs are associated
with the users in IPA, like subject name equal to LDAP DN? Or do we have to
just make the subject names meaningful and there's not any magic
association that would let us see when looking at a user in IPA that they
have a SSL cert assigned to them? I am hoping that after issuing a SSL to a
user, it would show up somehow in IPA that we have done so, when looking at
the user (versus manually having to cross check the list of issued SSLs for
one that matches the user).