Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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? -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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 :-) -- Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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 Do you want to fix it in current patch or should I create a ticket? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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 :-)) Do you want to fix it in current patch or should I create a ticket? Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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.) Petr^2 Spacek ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1066 requesting certs with subject alt name
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 I opened a ticket for better Subject Alternative Name check: https://fedorahosted.org/freeipa/ticket/3196 ACK for patch 1066. Pushed to master, ipa-3-0. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
