Petr Spacek wrote:
On 10/22/2012 02:40 PM, Simo Sorce wrote:
On Mon, 2012-10-22 at 13:01 +0200, Martin Kosek wrote:
On 10/22/2012 12:40 PM, Petr Spacek wrote:
On 10/19/2012 03:46 PM, Rob Crittenden wrote:
Petr Spacek wrote:
On 10/19/2012 03:10 PM, Rob Crittenden wrote:
Petr Spacek wrote:
On 10/19/2012 10:10 AM, Martin Kosek wrote:
On 10/18/2012 09:42 PM, Rob Crittenden wrote:
We were seeing a unicode failure when trying to request a
subject alt names. This one-liner should fix it.


Yup, this fixes it, works fine on --selfsign IPA CA too.

Just when testing your patch, I found out we don't treat some
alternative name well, e.g. email extension, an we try to match it
with our hosts:

Certificate Request:
          Requested Extensions:
              X509v3 Subject Alternative Name:

cert-request result:

ipa: ERROR: no host record for subject alt name in
certificate request

IMHO there should be a --force option. SAN can contain a lot of
different things. Also, we can't assume that we manage the whole
... (now :-))

The intention was just to provide support for DNS alt names. I don't
requiring a host entry exist for any alt hosts is asking too much.

I think a new ticket should be opened to support non-DNS alt names.

IMHO SAN names usually contain a lot of "virtual" names like,, etc.

These names are usually CNAMEs to "real" name like In
that case host object doesn't make sense. (But SAN is required for
proper certificate validation.)

The purpose is so we more tightly control was certificates are
issued by our
CA because we automatically issue them.


We discussed this check in Brno a bit and we found a problem:

1) Each SAN has to have corresponding host object (in current
2) Subject Alternative Name = other name for existing object
    E.g. Name is CNAME for
3) Host object makes sense for "real host", not for alias like "www"
4) Implication from points 1-3 => Current check can't pass in
reasonable case,
because aliases do not have own host objects.

Reasonable check can be: "There have to be host object for at least
one name
stated in certificate CN or SAN." (IMHO equivalence between CN and
host object
name would be probably better...)

Does it make sense?

I am also not a big fan of current SAN check. Making sure that a host
for the service host exists (it does, by design) is enough IMO. As
Petr said,
SANs are often just aliases for the host, so no need for a host record.

But I think if we insist on these checks, we may add --force option to
workaround the check or display the validation errors only as
warnings (when
the planned warning framework is ready - ticket #2732).

but I'd go further, I have found places where getting a DNS name
registered could take a couple of days (due to bad bureaucracy), in
those case you may not want to wait for that to happen, and keep going
(you can test with an entry in /etc/hosts in the meanwhile). So a
--force flag is something I think we really need.

I am all for checking and warning but outright preventing is wrong, the
admin is ultimately responsible and we shouldn't prevent admins from
doing operations unless they are fatally irreversible and would brick
the whole solution.

+5 (because was admin 9 months ago :-)

I'm not sure what you mean, it's been like this since inception years ago.

Cert operations are not limited to admins which is why this check is in place. A host may request tickets on its own behalf or on behalf of its services. I didn't want a host requesting certs for any old host on the network via SAN.

I'm fine with relaxing the rules but I'd like to do it via another permission such that one set of permissions allows for any SAN and the default limits SAN to known hosts.

This isn't linked to DNS in any way.


Freeipa-devel mailing list

Reply via email to