Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/29/2013 06:33 PM, Petr Viktorin wrote: > On 03/29/2013 06:17 PM, Petr Vobornik wrote: >> Hello, >> >> attaching Web UI part. >> >> Petr >> > > Works well for me, if someone can check if the Javascript looks fine then ACK. > I think that functional review is OK in this case, there are no architectonic changes... Pushed to master. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/29/2013 06:17 PM, Petr Vobornik wrote: Hello, attaching Web UI part. Petr Works well for me, if someone can check if the Javascript looks fine then ACK. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
Hello,
attaching Web UI part.
Petr
On 03/18/2013 12:58 PM, Petr Viktorin wrote:
Hello,
While the work is not complete, these patches allowed me to install an
IPA server without a CA, using PKCS#12 files for the server certs.
The patches don't break normal installation.
The --selfsign option (but not yet the code behind it) is removed.
The absence of a CA is indicated by `enable_ra=False` in the IPA config.
ipa-replica-install will still refuse to run; I'll look into that next.
I removed some unused code that got in my way: Dogtag 9 installation (we
can run a Dogtag 9-style CA, but we never *install* it), and
ipapython.certdb.CertDB (unused, not to be confused with ipaserver's
CertDB).
I tried using python-nss, but unfortunately found that it's not yet
usable here. John filed
https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our
conversation. Parsing certutil output, while dirty, is more reliable in
my limited experience.
I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper
around certdb operations. We have a CertDB class for it but that one is
too tied to the current code paths: when I used it I found myself
re-implementing a lot of methods to get rid of some assumption or other.
The new NSSDatabase is not tied to IPA configuration.
From what I've learned, PKCS#12 files are just a bag of certificates;
there are basically no restrictions on their contents. But we assume
there's only one cert inside that has a private key, and use that for
the server cert. We also pretty much assume that there's one CA cert: if
not we pick the first one and trust it as root CA.
In short, I think --http_pkcs & friends are too vague for PKCS#12s we
don't control; we should have the user name the certs more explicitly.
Am I wrong here? Is this the usual way to import server certs?
--
Petr Vobornik
From b6d775f8371343acfc9cef088c156431698af7b7 Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Thu, 28 Mar 2013 13:55:18 +0100
Subject: [PATCH] Web UI: Disable cert functionality if a CA is not available
Part of the work for: https://fedorahosted.org/freeipa/ticket/3363
---
install/ui/src/freeipa/certificate.js | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/install/ui/src/freeipa/certificate.js b/install/ui/src/freeipa/certificate.js
index 854a909accb35b0353102e02d986e8b6bd54941b..b4abcd7af4c1bdb3ff9d7861b92b4c1bd886bd51 100755
--- a/install/ui/src/freeipa/certificate.js
+++ b/install/ui/src/freeipa/certificate.js
@@ -501,7 +501,7 @@ IPA.cert.load_policy = function(spec) {
// show commands don't contain revocation_reason so previous data
// might be slightly incorrect
if (!that.has_reason && certificate && certificate.certificate &&
-!IPA.cert.is_selfsign()) {
+IPA.cert.is_enabled()) {
that.load_revocation_reason(certificate.serial_number);
}
};
@@ -529,8 +529,8 @@ IPA.cert.load_policy = function(spec) {
return that;
};
-IPA.cert.is_selfsign = function() {
-return IPA.env.ra_plugin == 'selfsign';
+IPA.cert.is_enabled = function() {
+return !!IPA.env.enable_ra;
};
IPA.cert.view_action = function(spec) {
@@ -604,6 +604,7 @@ IPA.cert.request_action = function(spec) {
spec = spec || {};
spec.name = spec.name || 'request_cert';
spec.label = spec.label || IPA.messages.objects.cert.new_certificate;
+spec.enable_cond = spec.enable_cond || ['ra_enabled'];
var that = IPA.action(spec);
that.entity_label = spec.entity_label;
@@ -660,7 +661,7 @@ IPA.cert.revoke_action = function(spec) {
spec.label = spec.label || IPA.messages.buttons.revoke;
spec.enable_cond = spec.enable_cond || ['has_certificate'];
spec.disable_cond = spec.disable_cond || ['certificate_revoked'];
-spec.hide_cond = spec.hide_cond || ['selfsign'];
+spec.hide_cond = spec.hide_cond || ['ra_disabled'];
spec.confirm_dialog = spec.confirm_dialog || IPA.cert.revoke_dialog;
spec.needs_confirm = spec.needs_confirm !== undefined ? spec.needs_confirm : true;
@@ -714,7 +715,7 @@ IPA.cert.restore_action = function(spec) {
spec.name = spec.name || 'restore_cert';
spec.label = spec.label || IPA.messages.buttons.restore;
spec.enable_cond = spec.enable_cond || ['has_certificate', 'certificate_hold'];
-spec.hide_cond = spec.hide_cond || ['selfsign'];
+spec.hide_cond = spec.hide_cond || ['ra_disabled'];
spec.confirm_msg = spec.confirm_msg || IPA.messages.objects.cert.restore_confirmation;
spec.confirm_dialog = spec.confirm_dialog || {
factory: IPA.confirm_dialog,
@@ -788,8 +789,10 @@ IPA.cert.certificate_evaluator = function(spec) {
}
}
-if (IPA.cert.is_selfsign()) {
-that.state.push('selfsign');
+if (IPA.cert.is_enabled()) {
+that.state.push('ra_enabled');
+} else {
+that.state.push('ra_disabled');
}
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On Fri, 2013-03-22 at 09:19 +0100, Martin Kosek wrote:
> On 03/21/2013 05:39 PM, Petr Viktorin wrote:
> > [...]
> >
> > another thing: When drafting the feature page, I realized the
> > --{http,dirsrv}_pin options are unfortunate. Giving the passwords in command
> > line options is unsafe.
> >
> > I'd like to replace them with --{http,dirsrv}-pin-file, with prompting if
> > they're not given.
> >
>
> How is that different from -p DM_PASSWORD and -a ADMIN_PASSWORD? They also
> cannot be read from file. I think these options would cause inconsistency with
> the rest of our password options in ipa-{server,client,replica}-install. It
> also seems as inconvenience to me as you need to prepare this artificial file
> before running ipa-server-install...
>
> I think it would be better to address this consistently in the future with
> configuration file instead of options, something like pkispawn uses.
Ack, I would defer securing the command line by introducing the ability
to pass in a configuration file.
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] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/21/2013 05:39 PM, Petr Viktorin wrote:
> [...]
>
> another thing: When drafting the feature page, I realized the
> --{http,dirsrv}_pin options are unfortunate. Giving the passwords in command
> line options is unsafe.
>
> I'd like to replace them with --{http,dirsrv}-pin-file, with prompting if
> they're not given.
>
How is that different from -p DM_PASSWORD and -a ADMIN_PASSWORD? They also
cannot be read from file. I think these options would cause inconsistency with
the rest of our password options in ipa-{server,client,replica}-install. It
also seems as inconvenience to me as you need to prepare this artificial file
before running ipa-server-install...
I think it would be better to address this consistently in the future with
configuration file instead of options, something like pkispawn uses.
Martin
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
[...]
another thing: When drafting the feature page, I realized the
--{http,dirsrv}_pin options are unfortunate. Giving the passwords in
command line options is unsafe.
I'd like to replace them with --{http,dirsrv}-pin-file, with prompting
if they're not given.
--
Petr³
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/20/2013 06:34 PM, Dmitri Pal wrote: On 03/20/2013 01:28 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 03/18/2013 10:24 PM, Rob Crittenden wrote: Petr Viktorin wrote: [...] From what I've learned, PKCS#12 files are just a bag of certificates; there are basically no restrictions on their contents. But we assume there's only one cert inside that has a private key, and use that for the server cert. We also pretty much assume that there's one CA cert: if not we pick the first one and trust it as root CA. In short, I think --http_pkcs & friends are too vague for PKCS#12s we don't control; we should have the user name the certs more explicitly. Am I wrong here? Is this the usual way to import server certs? We can impose a requirement that the CA be included in the PKCS#12 files. At least with NSS this happens automatically, I can't recall with openssl. Or we can add a new option to pass in the CA bundle in PEM format. After thinking about it, this is the way I want to go. It's a bit more typing for the user, but it reduces the amount of guesswork the installer needs to do. When deciding who to trust I'd rather be explicit. There's also a bit less validation to do and corner cases to watch out for. Yeah, I think this will simplify things a lot. The only downside is the requirement that both certs come from the same CA, but we have to draw the line somewhere. We can always look into extending things later on as needed. Well, if we allow more than one CA in the PEM we can lift this restriction. More below. The root CA certificate will be given by --external-ca-file. The trust chains for both servers (dirsrv, http) must lead to that CA. This CA will be trusted, and put in /etc/ipa/ca.crt. Just thinking out loud here, but will that cause any confusion, using an existing option? I don't think so but I may be too used to this. I don't think it would, but if we allow more than one CA (possibly in the future) there is a bigger chance of confusion after all. I'll use --root-ca-file instead. Each PKCS#12 file must contain exactly one cert with a private key. This cert will be used for the corresponding server. Of course you can use the same cert for both servers. I'm ok with that assuming we have an effective way of enforcing it. We'll need to provide some good documentation on how to create, or re-create, a PKCS#12 file to fit this format. Yes, enforcing this isn't hard. Creating is them easy too, it's the default (if not only) option in most tools. PKCS#12s with more than one cert chain are fairly exotic, from what I've read some Java tools that can use them but they run into interoperability problems. The --external_ca_file must contain exactly one cert. Certs for any intermediate CAs must be in the PKCS#12. It would be a lot easier to include all the CAs in a single PEM. This is not unprecedented, and just catting a bunch of certs together into a single file is easy and should not be error-prone. I don't want the whole chain in the PEM, because then it's not obvious which cert(s) to trust. We certainly don't want to give root trust to every cert in the chain. So if we allow more CAs here they'd have to be different *root* CAs. That would allow the server certs to be signed by different CAs, so I guess we want to do this. I don't know of a robust way to know that we have separate root CAs and not a chain (or several partial chains, etc.), so we'd have to document this well. But more importantly, this would mean we'd have to put several certs in /etc/ipa/ca.crt, and in LDAP. This is rather invasive so I'd like to stay out of this for now (but design so it's possible in the future). I think too we'll need to be able to handle the case of any Built-in certs. There is a chance we will need to simply drop on the floor any CA certs provided because some or all of them are already in NSS (all we really care about for this, I think). We still need to put something in /etc/ipa/ca.crt. I'll investigate what happens when I try to import and trust a cert that's already trusted, but I don't think it will cause any trouble? Does that look good? Does it need a design page? I think a design page would be particularly helpful in this case. I think this is going to be rather complex, and whatever choices we make to simplify things are going to be important. Yes the design is needed with the content of this thread plus some examples of the command line plus some hints & guidance on how to prepare files to be in the right format. This includes: How to check what format the files are? How many are there in the file? How to extact certs or or combine certs into files? How to save in the format we want/need? Explain why we require all this "more typing". We want to be explicit but we also want people to understand why we want them to be explicit. This is a very complex area and if we can explain why we ware requiring what we are requiring it would go a long way to
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/20/2013 01:28 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/18/2013 10:24 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >> [...] From what I've learned, PKCS#12 files are just a bag of certificates; there are basically no restrictions on their contents. But we assume there's only one cert inside that has a private key, and use that for the server cert. We also pretty much assume that there's one CA cert: if not we pick the first one and trust it as root CA. In short, I think --http_pkcs & friends are too vague for PKCS#12s we don't control; we should have the user name the certs more explicitly. Am I wrong here? Is this the usual way to import server certs? >>> >>> We can impose a requirement that the CA be included in the PKCS#12 >>> files. At least with NSS this happens automatically, I can't recall >>> with >>> openssl. >>> >>> Or we can add a new option to pass in the CA bundle in PEM format. >> >> After thinking about it, this is the way I want to go. It's a bit more >> typing for the user, but it reduces the amount of guesswork the >> installer needs to do. When deciding who to trust I'd rather be >> explicit. >> There's also a bit less validation to do and corner cases to watch >> out for. > > Yeah, I think this will simplify things a lot. The only downside is > the requirement that both certs come from the same CA, but we have to > draw the line somewhere. We can always look into extending things > later on as needed. > >> >> The root CA certificate will be given by --external-ca-file. The trust >> chains for both servers (dirsrv, http) must lead to that CA. This CA >> will be trusted, and put in /etc/ipa/ca.crt. > > Just thinking out loud here, but will that cause any confusion, using > an existing option? I don't think so but I may be too used to this. > >> >> Each PKCS#12 file must contain exactly one cert with a private key. This >> cert will be used for the corresponding server. >> Of course you can use the same cert for both servers. > > I'm ok with that assuming we have an effective way of enforcing it. > We'll need to provide some good documentation on how to create, or > re-create, a PKCS#12 file to fit this format. > >> >> The --external_ca_file must contain exactly one cert. Certs for any >> intermediate CAs must be in the PKCS#12. > > It would be a lot easier to include all the CAs in a single PEM. This > is not unprecedented, and just catting a bunch of certs together into > a single file is easy and should not be error-prone. > > I think too we'll need to be able to handle the case of any Built-in > certs. There is a chance we will need to simply drop on the floor any > CA certs provided because some or all of them are already in NSS (all > we really care about for this, I think). > >> Does that look good? Does it need a design page? > > I think a design page would be particularly helpful in this case. I > think this is going to be rather complex, and whatever choices we make > to simplify things are going to be important. Yes the design is needed with the content of this thread plus some examples of the command line plus some hints & guidance on how to prepare files to be in the right format. This includes: How to check what format the files are? How many are there in the file? How to extact certs or or combine certs into files? How to save in the format we want/need? Explain why we require all this "more typing". We want to be explicit but we also want people to understand why we want them to be explicit. This is a very complex area and if we can explain why we ware requiring what we are requiring it would go a long way to helping people understand what they are doing and what would the implication be. > >> >> I have some patches for this and for replication, but it'll take another >> day to polish and test them. > > Sounds great. > >> >> [...] >>> I'm not sure the dogtag 9 removal code really fits in the context of >>> these changes. It makes sense, but has nothing to do with this. >> >> I'll retire that patch for now. > > It would probably be a good idea to open a ticket and attach your > current work. > > thanks > > rob > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
Petr Viktorin wrote: On 03/18/2013 10:24 PM, Rob Crittenden wrote: Petr Viktorin wrote: [...] From what I've learned, PKCS#12 files are just a bag of certificates; there are basically no restrictions on their contents. But we assume there's only one cert inside that has a private key, and use that for the server cert. We also pretty much assume that there's one CA cert: if not we pick the first one and trust it as root CA. In short, I think --http_pkcs & friends are too vague for PKCS#12s we don't control; we should have the user name the certs more explicitly. Am I wrong here? Is this the usual way to import server certs? We can impose a requirement that the CA be included in the PKCS#12 files. At least with NSS this happens automatically, I can't recall with openssl. Or we can add a new option to pass in the CA bundle in PEM format. After thinking about it, this is the way I want to go. It's a bit more typing for the user, but it reduces the amount of guesswork the installer needs to do. When deciding who to trust I'd rather be explicit. There's also a bit less validation to do and corner cases to watch out for. Yeah, I think this will simplify things a lot. The only downside is the requirement that both certs come from the same CA, but we have to draw the line somewhere. We can always look into extending things later on as needed. The root CA certificate will be given by --external-ca-file. The trust chains for both servers (dirsrv, http) must lead to that CA. This CA will be trusted, and put in /etc/ipa/ca.crt. Just thinking out loud here, but will that cause any confusion, using an existing option? I don't think so but I may be too used to this. Each PKCS#12 file must contain exactly one cert with a private key. This cert will be used for the corresponding server. Of course you can use the same cert for both servers. I'm ok with that assuming we have an effective way of enforcing it. We'll need to provide some good documentation on how to create, or re-create, a PKCS#12 file to fit this format. The --external_ca_file must contain exactly one cert. Certs for any intermediate CAs must be in the PKCS#12. It would be a lot easier to include all the CAs in a single PEM. This is not unprecedented, and just catting a bunch of certs together into a single file is easy and should not be error-prone. I think too we'll need to be able to handle the case of any Built-in certs. There is a chance we will need to simply drop on the floor any CA certs provided because some or all of them are already in NSS (all we really care about for this, I think). Does that look good? Does it need a design page? I think a design page would be particularly helpful in this case. I think this is going to be rather complex, and whatever choices we make to simplify things are going to be important. I have some patches for this and for replication, but it'll take another day to polish and test them. Sounds great. [...] I'm not sure the dogtag 9 removal code really fits in the context of these changes. It makes sense, but has nothing to do with this. I'll retire that patch for now. It would probably be a good idea to open a ticket and attach your current work. thanks rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/18/2013 10:24 PM, Rob Crittenden wrote: Petr Viktorin wrote: [...] From what I've learned, PKCS#12 files are just a bag of certificates; there are basically no restrictions on their contents. But we assume there's only one cert inside that has a private key, and use that for the server cert. We also pretty much assume that there's one CA cert: if not we pick the first one and trust it as root CA. In short, I think --http_pkcs & friends are too vague for PKCS#12s we don't control; we should have the user name the certs more explicitly. Am I wrong here? Is this the usual way to import server certs? We can impose a requirement that the CA be included in the PKCS#12 files. At least with NSS this happens automatically, I can't recall with openssl. Or we can add a new option to pass in the CA bundle in PEM format. After thinking about it, this is the way I want to go. It's a bit more typing for the user, but it reduces the amount of guesswork the installer needs to do. When deciding who to trust I'd rather be explicit. There's also a bit less validation to do and corner cases to watch out for. The root CA certificate will be given by --external-ca-file. The trust chains for both servers (dirsrv, http) must lead to that CA. This CA will be trusted, and put in /etc/ipa/ca.crt. Each PKCS#12 file must contain exactly one cert with a private key. This cert will be used for the corresponding server. Of course you can use the same cert for both servers. The --external_ca_file must contain exactly one cert. Certs for any intermediate CAs must be in the PKCS#12. Does that look good? Does it need a design page? I have some patches for this and for replication, but it'll take another day to polish and test them. [...] I'm not sure the dogtag 9 removal code really fits in the context of these changes. It makes sense, but has nothing to do with this. I'll retire that patch for now. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/18/2013 10:24 PM, Rob Crittenden wrote: Petr Viktorin wrote: Hello, While the work is not complete, these patches allowed me to install an IPA server without a CA, using PKCS#12 files for the server certs. The patches don't break normal installation. The --selfsign option (but not yet the code behind it) is removed. The absence of a CA is indicated by `enable_ra=False` in the IPA config. ipa-replica-install will still refuse to run; I'll look into that next. I removed some unused code that got in my way: Dogtag 9 installation (we can run a Dogtag 9-style CA, but we never *install* it), and ipapython.certdb.CertDB (unused, not to be confused with ipaserver's CertDB). I tried using python-nss, but unfortunately found that it's not yet usable here. John filed https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our conversation. Parsing certutil output, while dirty, is more reliable in my limited experience. I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper around certdb operations. We have a CertDB class for it but that one is too tied to the current code paths: when I used it I found myself re-implementing a lot of methods to get rid of some assumption or other. The new NSSDatabase is not tied to IPA configuration. From what I've learned, PKCS#12 files are just a bag of certificates; there are basically no restrictions on their contents. But we assume there's only one cert inside that has a private key, and use that for the server cert. We also pretty much assume that there's one CA cert: if not we pick the first one and trust it as root CA. In short, I think --http_pkcs & friends are too vague for PKCS#12s we don't control; we should have the user name the certs more explicitly. Am I wrong here? Is this the usual way to import server certs? We can impose a requirement that the CA be included in the PKCS#12 files. At least with NSS this happens automatically, I can't recall with openssl. I think most tools will at least give you the option to export the whole trust chain. Or we can add a new option to pass in the CA bundle in PEM format. I guess we could reuse --external_ca_file for it. I'm not sure that order is guaranteed so I'm not sure your comparison that the DS and HTTP certs are signed by the same issuer will be true. In any case it may not matter, as long as they are trusted. It does raise the issue of what CA to put into /etc/ipa and LDAP but if it is an existing root cert there should be no issues. The real problem here is that since the order is not guaranteed, if there is more than one CA it might end up picking the wrong one to give root trust to. Receiving the CA cert explicitly would solve the issue. So there are really 2 use cases here: - They got certs from an upstream CA like Verisign, Thawte, etc. - They got certs from an internal CA. For case #1 there is probably nothing to do as the CAs are likely already trusted by the world. The second case needs to be handled more carefully. Even for case #1 we still need to put something in /etc/ipa/ca.crt. I guess in this case it would be the globally trusted root cert? There was a time, and it still may be the case, where we loosely handled the format of certificates. In some cases it was PEM, in others it was DER, and the only way you'd know is if you coded it or happened to look at the contents of the variable. We decided on trying to keep all certs internally in DER format, at least for the framework CA code. We typically use the variable dercert in that case. I didn't notice any inconsistencies, just something for you to be aware of. I'll keep it in mind. In my patch I mostly operate with nssdb names, because when the certs are imported I can check the flags. For find_server_certs() I wonder what happens if you pass in a PKCS#12 file with no CA's. It may not set any u flags if the cert comes from an unknown issuer, so we would report no server certificates found, but the real problem is no CA's found. AFAIK, "u" just means that we have the corresponding private key, so in this case you should get an error about CAs found. I'm not sure the dogtag 9 removal code really fits in the context of these changes. It makes sense, but has nothing to do with this. I had that patch almost ready. When I was doing the certs and some Dogtag 9 code got in my way I just took the patch, cleaned it up and included it. So yes, it touches a more than certs. Should I make a separate review thread for it? You can probably simplify the imports of certdb.py along with the code removal. Will do. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
Petr Viktorin wrote: Hello, While the work is not complete, these patches allowed me to install an IPA server without a CA, using PKCS#12 files for the server certs. The patches don't break normal installation. The --selfsign option (but not yet the code behind it) is removed. The absence of a CA is indicated by `enable_ra=False` in the IPA config. ipa-replica-install will still refuse to run; I'll look into that next. I removed some unused code that got in my way: Dogtag 9 installation (we can run a Dogtag 9-style CA, but we never *install* it), and ipapython.certdb.CertDB (unused, not to be confused with ipaserver's CertDB). I tried using python-nss, but unfortunately found that it's not yet usable here. John filed https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our conversation. Parsing certutil output, while dirty, is more reliable in my limited experience. I added ipaserver.install.certs.NSSDatabase as a general-purpose wrapper around certdb operations. We have a CertDB class for it but that one is too tied to the current code paths: when I used it I found myself re-implementing a lot of methods to get rid of some assumption or other. The new NSSDatabase is not tied to IPA configuration. From what I've learned, PKCS#12 files are just a bag of certificates; there are basically no restrictions on their contents. But we assume there's only one cert inside that has a private key, and use that for the server cert. We also pretty much assume that there's one CA cert: if not we pick the first one and trust it as root CA. In short, I think --http_pkcs & friends are too vague for PKCS#12s we don't control; we should have the user name the certs more explicitly. Am I wrong here? Is this the usual way to import server certs? We can impose a requirement that the CA be included in the PKCS#12 files. At least with NSS this happens automatically, I can't recall with openssl. Or we can add a new option to pass in the CA bundle in PEM format. I'm not sure that order is guaranteed so I'm not sure your comparison that the DS and HTTP certs are signed by the same issuer will be true. In any case it may not matter, as long as they are trusted. It does raise the issue of what CA to put into /etc/ipa and LDAP but if it is an existing root cert there should be no issues. So there are really 2 use cases here: - They got certs from an upstream CA like Verisign, Thawte, etc. - They got certs from an internal CA. For case #1 there is probably nothing to do as the CAs are likely already trusted by the world. The second case needs to be handled more carefully. There was a time, and it still may be the case, where we loosely handled the format of certificates. In some cases it was PEM, in others it was DER, and the only way you'd know is if you coded it or happened to look at the contents of the variable. We decided on trying to keep all certs internally in DER format, at least for the framework CA code. We typically use the variable dercert in that case. I didn't notice any inconsistencies, just something for you to be aware of. For find_server_certs() I wonder what happens if you pass in a PKCS#12 file with no CA's. It may not set any u flags if the cert comes from an unknown issuer, so we would report no server certificates found, but the real problem is no CA's found. I'm not sure the dogtag 9 removal code really fits in the context of these changes. It makes sense, but has nothing to do with this. You can probably simplify the imports of certdb.py along with the code removal. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs
On 03/18/2013 07:58 AM, Petr Viktorin wrote: > Hello, > While the work is not complete, these patches allowed me to install an > IPA server without a CA, using PKCS#12 files for the server certs. > > The patches don't break normal installation. > The --selfsign option (but not yet the code behind it) is removed. > > The absence of a CA is indicated by `enable_ra=False` in the IPA config. > > ipa-replica-install will still refuse to run; I'll look into that next. > > I removed some unused code that got in my way: Dogtag 9 installation > (we can run a Dogtag 9-style CA, but we never *install* it), and > ipapython.certdb.CertDB (unused, not to be confused with ipaserver's > CertDB). > > I tried using python-nss, but unfortunately found that it's not yet > usable here. John filed > https://bugzilla.redhat.com/show_bug.cgi?id=922247 after our > conversation. Parsing certutil output, while dirty, is more reliable > in my limited experience. > I added ipaserver.install.certs.NSSDatabase as a general-purpose > wrapper around certdb operations. We have a CertDB class for it but > that one is too tied to the current code paths: when I used it I found > myself re-implementing a lot of methods to get rid of some assumption > or other. The new NSSDatabase is not tied to IPA configuration. > > > From what I've learned, PKCS#12 files are just a bag of certificates; > there are basically no restrictions on their contents. But we assume > there's only one cert inside that has a private key, and use that for > the server cert. We also pretty much assume that there's one CA cert: > if not we pick the first one and trust it as root CA. > In short, I think --http_pkcs & friends are too vague for PKCS#12s we > don't control; we should have the user name the certs more explicitly. > Am I wrong here? Is this the usual way to import server certs? If we do not do anything about this now we should at least clearly document the assumptions and how things work to avoid surprises. > > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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
