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
certificate
with
subject alt names. This one-liner should fix it.
rob
Yup, this fixes it, works fine on --selfsign IPA CA too.
Just when testing your patch, I found out we don't treat some
non-DNS
subject
alternative name well, e.g. email extension, an we try to match it
with our hosts:
Certificate Request:
...
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
email:f...@testcert.example.com,
DNS:web.example.com
...
cert-request result:
ipa: ERROR: no host record for subject alt name
f...@testcert.example.com 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
world
... (now :-))
The intention was just to provide support for DNS alt names. I don't
think
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
www.shop1.com, ftp.shop1.com, etc.
These names are usually CNAMEs to "real" name like srv1.shop1.com. 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.
rob
We discussed this check in Brno a bit and we found a problem:
1) Each SAN has to have corresponding host object (in current
implementation)
2) Subject Alternative Name = other name for existing object
E.g. Name www.shop1.com is CNAME for srv1.shop1.com
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
record
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).
+1,
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.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
