Re: [Freeipa-devel] [RFE] CA-less install
On 04/02/2013 02:07 PM, John Dennis wrote: On 04/02/2013 11:33 AM, Petr Viktorin wrote: On 04/02/2013 02:14 AM, Robert Relyea wrote: On 03/29/2013 07:40 AM, John Dennis wrote: On 03/29/2013 07:57 AM, Petr Viktorin wrote: On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Does the new code include downloading and importing CRLs? Cert verification is a complex topic. This is further exacerbated by the introduction of PKIX. My understanding is NSS had "classic" verification code and later introduced PKIX. There has been an evolution between classic verification and PKIX. This is outside my domain of expertise. How and when CRL's are loaded in NSS is not something I can give advice on, especially in an area undergoing change. I'm going to have to defer to an expert in this area, Bob Relyea, I've CC'ed him on this email. It's hard to get the context in the middle, and and John had noted, NSS is transitioning from the old Cert_Verify interface to the new PKIX_ code. I'll answer the question for the traditional CERTVerify code, which is the only you get in SSL by default, and the one most people still use: No, CRLs are not downloaded and imported automatically, but if you download and import CRL's, NSS will use them. There's an installable PKCS #11 module which can be configured to download and install CRLs, then provide them to NSS. It's call mod_revocator. The expected revocation strategy NSS uses is OCSP, and you can turn on automatic OCSP fetching. Bob, to put this in context [1] the functionality in python-nss being discussed is the binding of the CERT_VerifyCertificate() function, something I added recently. Now the question arises as to how CRL's are meant to play into the verification process. Can you please explain how NSS expects this to be done? Pointers to existing documentation and code examples would also be helpful. There's a separate CERT_ImportCRL() which will import the CRL into the database. mod_revocator() can also be used to do the fetching for you, Matthew has examples on how various servers set them up (I believe the only NSS set up is installing the module in your secmod.db/pkcs11.txt with modutil. It would also be helpful to understand the PKIX roadmap and how this might affect coding decisions at the API level. the PKIX interface is available now, and is actually used by Chrome (for all certs) and Firefox (for ev processing). Firefox is in the process of moving to libpkix for everything. There is an environment variable you can set (I don't remember it specifically, but I could look it up for you if you want) that will cause the transitional CERT_VerifyCertificate() interface to use the libpkix engine, but it keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert fetching).. With libpkix, the revocation options are quite broad and complexed. We really expect people would use a set of preconfigured policies, though libpkix API allows for quite some variance. It would take me some time to dig up all the descriptions, but I can if you want them. [1] Some additional context, the original motivation for exposing NSS cert verification to IPA was to solve the following problem. If someone wants to make the IPA CA a sub-CA (as opposed to a self-signed CA) we want to validate the externally provided CA cert *before* proceeding with the IPA installation. This is because if the CA cert is invalid everything will hugely blow-up (because we use the CA cert to sign all the certs issued in IPA, especially those used to validate cooperating components/agents, if those certs do not work nothing in IPA works). In addition to this narrow goal we in general want to be able to perform cert verification correctly in other contexts as well so the extent to which you can educate us in general on this topic will be appreciated. OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless you specifically need some of the advanced libpkix features. The original context is sanity checking: is a SSL server cert we get from a user valid? If it is then we install the corresponding server. Requirements here are: - No extra information from the user, other than the cert itself (the admin gives us a cert, we don't want to ask how to find out if it's valid) - It needs to be a simple call/tool, since there's little gain over ju
Re: [Freeipa-devel] [RFE] CA-less install
On 04/02/2013 11:33 AM, Petr Viktorin wrote: On 04/02/2013 02:14 AM, Robert Relyea wrote: On 03/29/2013 07:40 AM, John Dennis wrote: On 03/29/2013 07:57 AM, Petr Viktorin wrote: On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Does the new code include downloading and importing CRLs? Cert verification is a complex topic. This is further exacerbated by the introduction of PKIX. My understanding is NSS had "classic" verification code and later introduced PKIX. There has been an evolution between classic verification and PKIX. This is outside my domain of expertise. How and when CRL's are loaded in NSS is not something I can give advice on, especially in an area undergoing change. I'm going to have to defer to an expert in this area, Bob Relyea, I've CC'ed him on this email. It's hard to get the context in the middle, and and John had noted, NSS is transitioning from the old Cert_Verify interface to the new PKIX_ code. I'll answer the question for the traditional CERTVerify code, which is the only you get in SSL by default, and the one most people still use: No, CRLs are not downloaded and imported automatically, but if you download and import CRL's, NSS will use them. There's an installable PKCS #11 module which can be configured to download and install CRLs, then provide them to NSS. It's call mod_revocator. The expected revocation strategy NSS uses is OCSP, and you can turn on automatic OCSP fetching. Bob, to put this in context [1] the functionality in python-nss being discussed is the binding of the CERT_VerifyCertificate() function, something I added recently. Now the question arises as to how CRL's are meant to play into the verification process. Can you please explain how NSS expects this to be done? Pointers to existing documentation and code examples would also be helpful. There's a separate CERT_ImportCRL() which will import the CRL into the database. mod_revocator() can also be used to do the fetching for you, Matthew has examples on how various servers set them up (I believe the only NSS set up is installing the module in your secmod.db/pkcs11.txt with modutil. It would also be helpful to understand the PKIX roadmap and how this might affect coding decisions at the API level. the PKIX interface is available now, and is actually used by Chrome (for all certs) and Firefox (for ev processing). Firefox is in the process of moving to libpkix for everything. There is an environment variable you can set (I don't remember it specifically, but I could look it up for you if you want) that will cause the transitional CERT_VerifyCertificate() interface to use the libpkix engine, but it keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert fetching).. With libpkix, the revocation options are quite broad and complexed. We really expect people would use a set of preconfigured policies, though libpkix API allows for quite some variance. It would take me some time to dig up all the descriptions, but I can if you want them. [1] Some additional context, the original motivation for exposing NSS cert verification to IPA was to solve the following problem. If someone wants to make the IPA CA a sub-CA (as opposed to a self-signed CA) we want to validate the externally provided CA cert *before* proceeding with the IPA installation. This is because if the CA cert is invalid everything will hugely blow-up (because we use the CA cert to sign all the certs issued in IPA, especially those used to validate cooperating components/agents, if those certs do not work nothing in IPA works). In addition to this narrow goal we in general want to be able to perform cert verification correctly in other contexts as well so the extent to which you can educate us in general on this topic will be appreciated. OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless you specifically need some of the advanced libpkix features. The original context is sanity checking: is a SSL server cert we get from a user valid? If it is then we install the corresponding server. Requirements here are: - No extra information from the user, other than the cert itself (the admin gives us a cert, we don't want to ask how to find out if it's valid) - It needs to be a simple call/tool, since there's little gain over just documenting that we want good certs. So it looks it's
Re: [Freeipa-devel] [RFE] CA-less install
On 04/02/2013 02:14 AM, Robert Relyea wrote: On 03/29/2013 07:40 AM, John Dennis wrote: On 03/29/2013 07:57 AM, Petr Viktorin wrote: On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Does the new code include downloading and importing CRLs? Cert verification is a complex topic. This is further exacerbated by the introduction of PKIX. My understanding is NSS had "classic" verification code and later introduced PKIX. There has been an evolution between classic verification and PKIX. This is outside my domain of expertise. How and when CRL's are loaded in NSS is not something I can give advice on, especially in an area undergoing change. I'm going to have to defer to an expert in this area, Bob Relyea, I've CC'ed him on this email. It's hard to get the context in the middle, and and John had noted, NSS is transitioning from the old Cert_Verify interface to the new PKIX_ code. I'll answer the question for the traditional CERTVerify code, which is the only you get in SSL by default, and the one most people still use: No, CRLs are not downloaded and imported automatically, but if you download and import CRL's, NSS will use them. There's an installable PKCS #11 module which can be configured to download and install CRLs, then provide them to NSS. It's call mod_revocator. The expected revocation strategy NSS uses is OCSP, and you can turn on automatic OCSP fetching. Bob, to put this in context [1] the functionality in python-nss being discussed is the binding of the CERT_VerifyCertificate() function, something I added recently. Now the question arises as to how CRL's are meant to play into the verification process. Can you please explain how NSS expects this to be done? Pointers to existing documentation and code examples would also be helpful. There's a separate CERT_ImportCRL() which will import the CRL into the database. mod_revocator() can also be used to do the fetching for you, Matthew has examples on how various servers set them up (I believe the only NSS set up is installing the module in your secmod.db/pkcs11.txt with modutil. It would also be helpful to understand the PKIX roadmap and how this might affect coding decisions at the API level. the PKIX interface is available now, and is actually used by Chrome (for all certs) and Firefox (for ev processing). Firefox is in the process of moving to libpkix for everything. There is an environment variable you can set (I don't remember it specifically, but I could look it up for you if you want) that will cause the transitional CERT_VerifyCertificate() interface to use the libpkix engine, but it keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert fetching).. With libpkix, the revocation options are quite broad and complexed. We really expect people would use a set of preconfigured policies, though libpkix API allows for quite some variance. It would take me some time to dig up all the descriptions, but I can if you want them. [1] Some additional context, the original motivation for exposing NSS cert verification to IPA was to solve the following problem. If someone wants to make the IPA CA a sub-CA (as opposed to a self-signed CA) we want to validate the externally provided CA cert *before* proceeding with the IPA installation. This is because if the CA cert is invalid everything will hugely blow-up (because we use the CA cert to sign all the certs issued in IPA, especially those used to validate cooperating components/agents, if those certs do not work nothing in IPA works). In addition to this narrow goal we in general want to be able to perform cert verification correctly in other contexts as well so the extent to which you can educate us in general on this topic will be appreciated. OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless you specifically need some of the advanced libpkix features. The original context is sanity checking: is a SSL server cert we get from a user valid? If it is then we install the corresponding server. Requirements here are: - No extra information from the user, other than the cert itself (the admin gives us a cert, we don't want to ask how to find out if it's valid) - It needs to be a simple call/tool, since there's little gain over just documenting that we want good certs. So it looks it's not worth it to go there. The new conte
Re: [Freeipa-devel] [RFE] CA-less install
On 03/22/2013 01:10 PM, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? Since the patches were pushed, I've linked the RFE in http://freeipa.org/page/V3_Designs -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/29/2013 07:40 AM, John Dennis wrote: On 03/29/2013 07:57 AM, Petr Viktorin wrote: On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Does the new code include downloading and importing CRLs? Cert verification is a complex topic. This is further exacerbated by the introduction of PKIX. My understanding is NSS had "classic" verification code and later introduced PKIX. There has been an evolution between classic verification and PKIX. This is outside my domain of expertise. How and when CRL's are loaded in NSS is not something I can give advice on, especially in an area undergoing change. I'm going to have to defer to an expert in this area, Bob Relyea, I've CC'ed him on this email. It's hard to get the context in the middle, and and John had noted, NSS is transitioning from the old Cert_Verify interface to the new PKIX_ code. I'll answer the question for the traditional CERTVerify code, which is the only you get in SSL by default, and the one most people still use: No, CRLs are not downloaded and imported automatically, but if you download and import CRL's, NSS will use them. There's an installable PKCS #11 module which can be configured to download and install CRLs, then provide them to NSS. It's call mod_revocator. The expected revocation strategy NSS uses is OCSP, and you can turn on automatic OCSP fetching. Bob, to put this in context [1] the functionality in python-nss being discussed is the binding of the CERT_VerifyCertificate() function, something I added recently. Now the question arises as to how CRL's are meant to play into the verification process. Can you please explain how NSS expects this to be done? Pointers to existing documentation and code examples would also be helpful. There's a separate CERT_ImportCRL() which will import the CRL into the database. mod_revocator() can also be used to do the fetching for you, Matthew has examples on how various servers set them up (I believe the only NSS set up is installing the module in your secmod.db/pkcs11.txt with modutil. It would also be helpful to understand the PKIX roadmap and how this might affect coding decisions at the API level. the PKIX interface is available now, and is actually used by Chrome (for all certs) and Firefox (for ev processing). Firefox is in the process of moving to libpkix for everything. There is an environment variable you can set (I don't remember it specifically, but I could look it up for you if you want) that will cause the transitional CERT_VerifyCertificate() interface to use the libpkix engine, but it keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert fetching).. With libpkix, the revocation options are quite broad and complexed. We really expect people would use a set of preconfigured policies, though libpkix API allows for quite some variance. It would take me some time to dig up all the descriptions, but I can if you want them. [1] Some additional context, the original motivation for exposing NSS cert verification to IPA was to solve the following problem. If someone wants to make the IPA CA a sub-CA (as opposed to a self-signed CA) we want to validate the externally provided CA cert *before* proceeding with the IPA installation. This is because if the CA cert is invalid everything will hugely blow-up (because we use the CA cert to sign all the certs issued in IPA, especially those used to validate cooperating components/agents, if those certs do not work nothing in IPA works). In addition to this narrow goal we in general want to be able to perform cert verification correctly in other contexts as well so the extent to which you can educate us in general on this topic will be appreciated. OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless you specifically need some of the advanced libpkix features. smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 10:19 PM, Orion Poplawski wrote: > On 03/27/2013 10:42 AM, Petr Viktorin wrote: >> On 03/27/2013 05:09 PM, Rob Crittenden wrote: >> [...] Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... >>> >>> We're talking a one-time operation. I don't think it's asking too much. >>> It also gives the user some amount of control rather than assuming that >>> whatever tool their using to create the PKCS#12 file is also smart >>> enough to include the right CAs. >> >> Well, to be fair, if there are any intermediate CAs, they need to be in >> the PKCS#12. (In the future there may be support for multiple root CAs, >> which would all get explicit trust. Those would all go in the PEM, so >> intermediate ones must be somewhere else -- in the PKCS#12.) >> >> Anyway I think it's unlikely that everybody will have the certs in the >> right format for IPA by default, whatever that format is. >> Honza has a point, but... If one solution is clearly better (in terms of >> best/common practices in organizations this feature is for), I'm happy >> to change it. Otherwise let's paint the bikeshed with the color I have >> ready :) > > FWIW (about $0.02), it did take me a while to figure out how to create > pkcs12 files that included the CA certificate chain out of the PEM > files given to me by my CA that ipa needed. Might be nice to have > that in docs somewhere. But I can live with this color of bikeshed :) > > > Would you mind writing a page or a blog about it? That would be really appreciated. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/22/2013 01:10 PM, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? I have added "Affected commands" and "Clients" sections to the RFE. Since I mentioned host-mod which takes certs in yet another format, I've added a "Base64-encoded DER certificates" section as well. == Affected commands == IPA's cert plugin and cert-* commands will not be available at all. Calling them will result in CommandError (code 905) No online help will be available on them, or on the "cert" topic. Certificates removed from LDAP will not be automatically revoked. This affects the following commands: * host-del * host-mod * host-disable * service-del * service-mod * service-disable == Clients == Clients in a CA-less IPA installation will work normally, except host certificates will not be assigned automatically. Older clients configure certmonger to obtain the host certificate, which will fail, with the folloging line apparing periodically in the system log: Server failed request, will retry: 905 (RPC failed at server. unknown command 'cert_request'). The errors can be stopped by issuing: # getcert list # to find out the certmonger request ID # getcert stop-tracking If needed, machine certificates may be obtained from the external CA and added to the server with: ipa host-mod --certificate --- === Base64-encoded DER certificates === The letters and symbols between a PEM file's BEGIN CERTIFICATE and END CERTIFICATE markers are a base64-encoded DER-encoded X.509 certificate. To convert between PEM and base64-encoded DER, just add or remove the markers in a text editor. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/29/2013 07:57 AM, Petr Viktorin wrote: On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Does the new code include downloading and importing CRLs? Cert verification is a complex topic. This is further exacerbated by the introduction of PKIX. My understanding is NSS had "classic" verification code and later introduced PKIX. There has been an evolution between classic verification and PKIX. This is outside my domain of expertise. How and when CRL's are loaded in NSS is not something I can give advice on, especially in an area undergoing change. I'm going to have to defer to an expert in this area, Bob Relyea, I've CC'ed him on this email. Bob, to put this in context [1] the functionality in python-nss being discussed is the binding of the CERT_VerifyCertificate() function, something I added recently. Now the question arises as to how CRL's are meant to play into the verification process. Can you please explain how NSS expects this to be done? Pointers to existing documentation and code examples would also be helpful. It would also be helpful to understand the PKIX roadmap and how this might affect coding decisions at the API level. [1] Some additional context, the original motivation for exposing NSS cert verification to IPA was to solve the following problem. If someone wants to make the IPA CA a sub-CA (as opposed to a self-signed CA) we want to validate the externally provided CA cert *before* proceeding with the IPA installation. This is because if the CA cert is invalid everything will hugely blow-up (because we use the CA cert to sign all the certs issued in IPA, especially those used to validate cooperating components/agents, if those certs do not work nothing in IPA works). In addition to this narrow goal we in general want to be able to perform cert verification correctly in other contexts as well so the extent to which you can educate us in general on this topic will be appreciated. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Does the new code include downloading and importing CRLs? Finding time to work on python-nss has been a problem. This is further complicated by the fact Mozilla has changed from CVS to Mercurial while I had this code in development and I haven't moved over to the new distributed SCM yet. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 10:42 AM, Petr Viktorin wrote: On 03/27/2013 05:09 PM, Rob Crittenden wrote: [...] Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. Well, to be fair, if there are any intermediate CAs, they need to be in the PKCS#12. (In the future there may be support for multiple root CAs, which would all get explicit trust. Those would all go in the PEM, so intermediate ones must be somewhere else -- in the PKCS#12.) Anyway I think it's unlikely that everybody will have the certs in the right format for IPA by default, whatever that format is. Honza has a point, but... If one solution is clearly better (in terms of best/common practices in organizations this feature is for), I'm happy to change it. Otherwise let's paint the bikeshed with the color I have ready :) FWIW (about $0.02), it did take me a while to figure out how to create pkcs12 files that included the CA certificate chain out of the PEM files given to me by my CA that ipa needed. Might be nice to have that in docs somewhere. But I can live with this color of bikeshed :) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 12:44 PM, Petr Viktorin wrote: On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Thanks! I'll take a look at it again. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. I'll add verify_hostname from the validation example; if there's anything else please give me a pointer -- I haven't read all the docs, yet. doc/examples/verify_server.py test/test_client_server.py illustrate example usage. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 12:42 PM, Petr Viktorin wrote: On 03/27/2013 05:09 PM, Rob Crittenden wrote: [...] Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. Well, to be fair, if there are any intermediate CAs, they need to be in the PKCS#12. (In the future there may be support for multiple root CAs, which would all get explicit trust. Those would all go in the PEM, so intermediate ones must be somewhere else -- in the PKCS#12.) Anyway I think it's unlikely that everybody will have the certs in the right format for IPA by default, whatever that format is. Honza has a point, but... If one solution is clearly better (in terms of best/common practices in organizations this feature is for), I'm happy to change it. Otherwise let's paint the bikeshed with the color I have ready :) [...] I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? certutil -V -u V will do it. The usage is already checked -- and with this command, too :) The problem here is hostname validation. I don't think it would be onerous to assure that either the FQDN is in the CN or it is a '*'. python-nss has fairly easy ways to grab the subject out of a cert for this comparison. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. One of the many cases that we will need to handle. I found that python-nss has a verify_hostname call. I'll add it. It also has Certificate.verify_now(). There are examples of usage in either the doc/examples directory or the test directory. NB, the cert has to be in the database, a possible limitation for the intended usage. The enhanced unreleased code dispenses with that restriction and adds additional functionality. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 04:40 PM, John Dennis wrote: On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Thanks! I'll take a look at it again. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. I'll add verify_hostname from the validation example; if there's anything else please give me a pointer -- I haven't read all the docs, yet. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 05:09 PM, Rob Crittenden wrote: [...] Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. Well, to be fair, if there are any intermediate CAs, they need to be in the PKCS#12. (In the future there may be support for multiple root CAs, which would all get explicit trust. Those would all go in the PEM, so intermediate ones must be somewhere else -- in the PKCS#12.) Anyway I think it's unlikely that everybody will have the certs in the right format for IPA by default, whatever that format is. Honza has a point, but... If one solution is clearly better (in terms of best/common practices in organizations this feature is for), I'm happy to change it. Otherwise let's paint the bikeshed with the color I have ready :) [...] I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? certutil -V -u V will do it. The usage is already checked -- and with this command, too :) The problem here is hostname validation. I don't think it would be onerous to assure that either the FQDN is in the CN or it is a '*'. python-nss has fairly easy ways to grab the subject out of a cert for this comparison. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. One of the many cases that we will need to handle. I found that python-nss has a verify_hostname call. I'll add it. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 04:40 PM, Jan Cholasta wrote: On 27.3.2013 16:23, Petr Viktorin wrote: On 03/27/2013 03:44 PM, Jan Cholasta wrote: I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. Well, --root-ca-file specifies the root of trust, not necessarily the selfsigned/unsigned CA at end of the trust chain. Suppose you have a company-wide cert signed by a "globally" trusted CA, but you're paranoid only want to trust the company cert, not a CA that signs half the world's certificates. In that case walking up the chain would select the wrong certificate. Please correct me if my thinking is wrong. Makes sense, thanks. Can you please put this information in the RFE page? Added. Yes, a --root-ca-subject would work too. I assumed the PEM file is readily available. Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... Well, if the PKCS#12 only has the server cert that's signed directly by the CA, there's no duplication. This is arguably the common case. Honestly, I don't know what would be easier for a typical sysadmin in an organization that needs this functionality. These two approaches seem pretty even to me. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN= (or CN=*. if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. I'll see how python-nss can help here. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
Jan Cholasta wrote: On 27.3.2013 16:23, Petr Viktorin wrote: On 03/27/2013 03:44 PM, Jan Cholasta wrote: I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. Well, --root-ca-file specifies the root of trust, not necessarily the selfsigned/unsigned CA at end of the trust chain. Suppose you have a company-wide cert signed by a "globally" trusted CA, but you're paranoid only want to trust the company cert, not a CA that signs half the world's certificates. In that case walking up the chain would select the wrong certificate. Please correct me if my thinking is wrong. Makes sense, thanks. Can you please put this information in the RFE page? Yes, a --root-ca-subject would work too. I assumed the PEM file is readily available. Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We're talking a one-time operation. I don't think it's asking too much. It also gives the user some amount of control rather than assuming that whatever tool their using to create the PKCS#12 file is also smart enough to include the right CAs. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN= (or CN=*. if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? certutil -V -u V will do it. I don't think it would be onerous to assure that either the FQDN is in the CN or it is a '*'. python-nss has fairly easy ways to grab the subject out of a cert for this comparison. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. One of the many cases that we will need to handle. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 11:23 AM, Petr Viktorin wrote: I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? Yes. NSS provides a variety of tools to test validation. Going just on memory here, our current version of python-nss has a simple call to test validation. Sometime in the last year I added a fair amount of new support for certificate validation including getting back diagnostic information for validation failures, however if I recall correctly the extended functionality in python-nss has not been released yet. Finding time to work on python-nss has been a problem. This is further complicated by the fact Mozilla has changed from CVS to Mercurial while I had this code in development and I haven't moved over to the new distributed SCM yet. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 27.3.2013 16:23, Petr Viktorin wrote: On 03/27/2013 03:44 PM, Jan Cholasta wrote: I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. Well, --root-ca-file specifies the root of trust, not necessarily the selfsigned/unsigned CA at end of the trust chain. Suppose you have a company-wide cert signed by a "globally" trusted CA, but you're paranoid only want to trust the company cert, not a CA that signs half the world's certificates. In that case walking up the chain would select the wrong certificate. Please correct me if my thinking is wrong. Makes sense, thanks. Can you please put this information in the RFE page? Yes, a --root-ca-subject would work too. I assumed the PEM file is readily available. Well, I don't like how PEM file duplicates an unnecessary amount of information (the whole certificate). Also, copy-pasting subject might be faster than exporting certificate in PEM and uploading it to the server... We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN= (or CN=*. if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. I'm not sure TBH. Maybe someone with more NSS experience could answer this? The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Actually I didn't check this specifically. But, I used a server certificate with wrong subject and that made ipa-server-install fail. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/27/2013 03:44 PM, Jan Cholasta wrote: Hi, On 22.3.2013 13:10, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. Well, --root-ca-file specifies the root of trust, not necessarily the selfsigned/unsigned CA at end of the trust chain. Suppose you have a company-wide cert signed by a "globally" trusted CA, but you're paranoid only want to trust the company cert, not a CA that signs half the world's certificates. In that case walking up the chain would select the wrong certificate. Please correct me if my thinking is wrong. Yes, a --root-ca-subject would work too. I assumed the PEM file is readily available. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN= (or CN=*. if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. I don't want to check the subject because this RFE was prompted by IPA's normal CA rejecting valid wildcart certs. Is there a reasonable way to ask NSS if it will trust the cert? If there is I can put it in, but I don't want to re-create the validation. The code checks for the whole cert chain, and that's there only one server cert. Does that not work? Also, the RFE page states that the options to specify PKCS#12 files are called --http_pkcs and --dirsrv_pkcs, but they are in fact called --http_pkcs12 and --dirsrv_pkcs12. Fixed, thanks. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
Hi, On 22.3.2013 13:10, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? I have gone through the whole discussion, RFE page and your patches, and I still don't see why --root-ca-file is necessary. Walking the certificate chain from the server cert up to the root CA is easy, so why not do that to determine the root CA? If the option is there just to ensure that the right certificate is used, I think it would be better to ask the user to confirm that during the installation process, or use --root-ca-subject or similar option to specify what certificate to use. We should do some validation of the PKCS#12 files and the certificates within them, as currently ipa-server-install will happily accept anything thrown at it. I think the minimum is to validate that the PKCS#12 file contains the whole certificate chain, the server key and only that, and that the server certificate has CN= (or CN=*. if we want to allow wildcard certs) in its subject. If we don't do that, ipa-server-install might fail when it's too late to fix things. Also, the RFE page states that the options to specify PKCS#12 files are called --http_pkcs and --dirsrv_pkcs, but they are in fact called --http_pkcs12 and --dirsrv_pkcs12. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/22/2013 01:32 PM, Dmitri Pal wrote: On 03/22/2013 08:10 AM, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? Petr, It answers a lot of questions. However isn't the whole goal to be able to use external CA we do not have control of as a part of the trust chain? I might very well confuse things so bear with me. Say I have a public CA X I want to use as the root of my trust chain so that I do not need to distribute certificates to all my clients. I can't create a sub CA using externa-ca because it will cost me a lot of money. But I can create a PKI pair for just two servers (HTTP and DS) much cheaper. Is this the assumption? Is this really how this works? Is it really easy to get a CRS signed by a public CA X? IMO one case is that there's a single corporate (not necessarily public) CA, with a policy that it will not sign subordinate CA certs, but it can sign server certs? Your case works too. Yes, server CSRs are easier to get signed than CA ones. (Do you mean "globally trusted" when you say public? With a globally trusted CA you can pretty much impersonate anybody on the Internet.) Someone familiar with certification policies should chime in if you need more details. I've learned a lot about the technical details but policies are another thing. Other comments: what are the implications on the certmonger and cert rotation. I assume certmonger will be turn off. It should then be documented that we will not track or warn about the cert expiration. Yes, Certmonger is not installed, cert rotation must be handled manually. I've udated the page. In future for the KDC pkinit support we will need yet another cert for the KDC, you do nto need to implement it now but please consider this in the design. Added to the page. Page misses you as an author. Added. I've also added an author section to [[Feature template]] so I remember next time. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
Dmitri Pal wrote: On 03/22/2013 08:10 AM, Petr Viktorin wrote: The design page for CA-less installation with user-provided SSL certs is available at http://freeipa.org/page/V3/CA-less_install. I've also copied it to this mail. Does it answer all your questions? Petr, It answers a lot of questions. However isn't the whole goal to be able to use external CA we do not have control of as a part of the trust chain? I might very well confuse things so bear with me. Say I have a public CA X I want to use as the root of my trust chain so that I do not need to distribute certificates to all my clients. I can't create a sub CA using externa-ca because it will cost me a lot of money. But I can create a PKI pair for just two servers (HTTP and DS) much cheaper. Is this the assumption? Is this really how this works? Is it really easy to get a CRS signed by a public CA X? Yes, it really can be that easy. Most of the requests in this area have involved using wildcard certs which are slightly more complex to get, but you can get free SSL server certs from StartSSL in less than 30 minutes (providing you can prove you manage the domain you're requesting certs for). I imagine that most will use the same cert for both services, rather than getting separate certs. Other comments: what are the implications on the certmonger and cert rotation. I assume certmonger will be turn off. It should then be documented that we will not track or warn about the cert expiration. Right, we won't be able to leverage certmonger. Users will be on their own to handle renewal. In future for the KDC pkinit support we will need yet another cert for the KDC, you do nto need to implement it now but please consider this in the design. This is a grey area. I don't know if the public CAs will issue this kind of cert. A survey would be required to find out. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFE] CA-less install
On 03/22/2013 08:10 AM, Petr Viktorin wrote: > The design page for CA-less installation with user-provided SSL certs > is available at http://freeipa.org/page/V3/CA-less_install. I've also > copied it to this mail. > > Does it answer all your questions? > Petr, It answers a lot of questions. However isn't the whole goal to be able to use external CA we do not have control of as a part of the trust chain? I might very well confuse things so bear with me. Say I have a public CA X I want to use as the root of my trust chain so that I do not need to distribute certificates to all my clients. I can't create a sub CA using externa-ca because it will cost me a lot of money. But I can create a PKI pair for just two servers (HTTP and DS) much cheaper. Is this the assumption? Is this really how this works? Is it really easy to get a CRS signed by a public CA X? Other comments: what are the implications on the certmonger and cert rotation. I assume certmonger will be turn off. It should then be documented that we will not track or warn about the cert expiration. In future for the KDC pkinit support we will need yet another cert for the KDC, you do nto need to implement it now but please consider this in the design. Page misses you as an author. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
