On 25.4.2016 18:05, EXT Alexander Bokovoy wrote:
On Mon, 25 Apr 2016, Rob Crittenden wrote:
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
........
-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----
It is denied by IPA, not certmonger.
IP addresses are frowned upon in certs in general and they are denied
by IPA because the access control would be really difficult. Today a
host must be granted access to issue certs with additional names in it.
You can open a RFE for this on the IPA trac if you really need it.
I'm not deeply familiar with the new profile support so perhaps it is
possible to do this using the latest version of IPA, I'm not sure.
Correct and no, it is not right now.
Certificate profile defines what CA considers possible to grant when
issuing a cert. CA doesn't have contextual logic -- that would be
provided by an agent approving the cert. IPA framework is sitting in
front of CA to put the context in place and could be considered such an
agent, so we have logic to cross-check the request for fields that would
be conflicting with IPA access controls.
As it happens now, IPA framework disallows IP addresses. Adding support
for that would need to get proper logic in place to decide which
address spaces to allow being managing by a requesting party -- a host
in your case as certmonger asks for the cert on behalf of the host. We
don't have any system in place for that.
Because I am not an expert on IPA / cert-business I might over-simplify
the case.
To me letting to add to SAN an IP address of related FQDN would be quite
simple case. When I am requesting cert for ipa2.public.domain and
ipa2.management.domain and wanting to have also their IPs in SAN
extension of the cert. The logic would be something like; IPA framework
checks that related FQDNs and their DNS information is in place in IPA
=> allow
There probably are much more complicated cases though. I understand that
to create huge number of exceptions for all the possible cases would be
mission impossible. Thus it would be nice if there would be possibility
for ipa admin to create this kind of rules to allow local exceptions --
even frowned ones.
In my original email I promised not to go details why I'd need the
feature, but here we go...
In our case the IP in SAN would be needed because our lab has its own
DNS space that is not published to intranet side. However there are
situations when user needs / wants to connect certain web services in
lab also from intranet (to change his password on IPA for example). In
such cases he has to give URL with IP address, but browsers tell that
the certificate is invalid because the cert is only valid for FQDN.
Naturally it is possible to create an exception on browser or add
/etc/hots entry for FQDN on intranet computer. However to me IP in SAN
would be much more elegant and clean solution.
--
tuomo.tikka...@nokia.com
--
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