On Tue, 26 Apr 2016, Tikkanen, Tuomo (Nokia - FI/Espoo) wrote:
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
We don't have for a general case any means to rely on the IP address <->
host name mapping. For cases where there is DNS zone managed by IPA we
might add a logic, I agree, but not in general unless there is DNSSEC in
place -- because with DNSSEC we could at least be able to verify
signatures on the records to see if we could trust the data.
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.
I understand you pain. You can file a ticket with a feature request for
that use case.
--
/ Alexander Bokovoy
--
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
