This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

moving bug to target 7.0, if will be writing CA certs to another location as trusted, needs to be an authenticated action.

Generally authentication is only needed when managing private keys in an NSS database, not adding certificates.

This RFE could use some fleshing out.

Which database would the IPA CA certificate be saved to?
Which trust flags should it be setting in the database for the certificate?
Would it be just one database, or would there be multiple locations?
Would certmonger be retrieving the root certificate from the server, or reading it from a specified location on the local filesystem?

(In reply to comment #4)
> Generally authentication is only needed when managing private keys in an NSS
> database, not adding certificates.

That certificate, because we're putting trust in it, needs to have been retrieved over an authenticated path.  I'm really uncomfortable with the idea of adding it to the set of trusted certificates in a given database when I know that this hasn't been guaranteed.

1. It would save it to whichever database certmonger is tracking a server cert for.
2. Good question, probably should not be hardcoded. I guess a reasonable default for an IPA world is CT,,C
3. I think it would be a per-tracking basis. This might make for either extra work or extra complexity (or both).
4. This is something I think could be hardcoded for some modicum of protection, /etc/ipa/ca.crt. On all clients and servers that should represent the IPA CA.

(In reply to comment #6)
> 1. It would save it to whichever database certmonger is tracking a server
> cert for.

Ah, so your intent is to have the CA's certificate stored in the same database as the newly-obtained certificate, as a side-effect, when we go to save the newly-obtained certificate.  That wasn't clear before.

> 2. Good question, probably should not be hardcoded. I guess a reasonable
> default for an IPA world is CT,,C

I see CT,C,C used in /etc/httpd.conf in IPA 2.2.  Is this 

> 3. I think it would be a per-tracking basis. This might make for either
> extra work or extra complexity (or both).

Hmm... maybe.  I was thinking of the complexity we'd have to cope with if the list of locations was tracked on a per-CA basis, not on a side-effect-of-a-per-request basis.

> 4. This is something I think could be hardcoded for some modicum of
> protection, /etc/ipa/ca.crt. On all clients and servers that should
> represent the IPA CA.

If we look ahead to the point when the CA's own certificate is replaced, I think that we're going to want to be able to have certmonger update the copy in that location as well.  That leaves open the question of what location certmonger should look to as the definitive source for the certificate.

The use case is this: you have an IPA client machine and you want to run an SSL service on it. You can use certmonger to automatically get a certificate for you, which once installed won't actually work because you lack the CA to go with it, so it's a two-step process. The request was to make it one-stop-shopping.

The middle tuple is S/MIME which may be overkill (heck, even object-signing is a bit of a stretch). It doesn't hurt though, CT,C,C is fine.

When we requested this it was in the scope of IPA so there was only one CA to consider. I think tracking the CA per request is probably fine, you just need a way to resolve if two requests are from the same database. You can't assume they have the same CA. But installing the same CA twice should be fine (a no-op, really).

Fetching the CA remotely is a bit of a chicken-and-egg problem. We do publish a non-secured copy of it in IPA, but the question is: is it trustworthy? We've decided it is, esp since we use it right after we request it and therefore confirm that it is the right one.

NSS has some validation routines, you could probably use one of those to confirm that the cert chain remains unbroken for the cert you already have. I suspect that openssl probably has equivalent calls.

(In reply to comment #8)
> The use case is this: you have an IPA client machine and you want to run an
> SSL service on it. You can use certmonger to automatically get a certificate
> for you, which once installed won't actually work because you lack the CA to
> go with it, so it's a two-step process. The request was to make it
> one-stop-shopping.
> 
> The middle tuple is S/MIME which may be overkill (heck, even object-signing
> is a bit of a stretch). It doesn't hurt though, CT,C,C is fine.

Does it impact the verification of signatures generated by the caJarSigningCert certificate?

> When we requested this it was in the scope of IPA so there was only one CA
> to consider. I think tracking the CA per request is probably fine, you just
> need a way to resolve if two requests are from the same database. You can't
> assume they have the same CA. But installing the same CA twice should be
> fine (a no-op, really).

If there are two certificates from different CAs in the same database, then only one of those CAs is going to be able to have the nickname "$DOMAIN IPA CA" set for its certificate.  What's supposed to happen then?

Installing the same CA certificate with the same nickname, twice, should be a no-op, I agree.

> Fetching the CA remotely is a bit of a chicken-and-egg problem. We do
> publish a non-secured copy of it in IPA, but the question is: is it
> trustworthy?  We've decided it is, esp since we use it right after we request
> it and therefore confirm that it is the right one.

If we accept that the CA's certificate will eventually be replaced, we need to find a way to provide a copy of the replacement certificate to clients via an authenticated path.

We're about to start publishing CA subsystem certificates to the IPA directory service.  If we put the CA's signing certificate in there, too, then the client would be able to fetch it at any time by performing a GSSAPI-authenticated LDAP search.

(In reply to comment #9)
> Does it impact the verification of signatures generated by the
> caJarSigningCert certificate?

It depends on how forward thinking we want to be. Today, no, it wouldn't. IPA issues only server certs so object signing would never come into play. If we issue identity certs for users then we might end up using certmonger to monitor their Firefox/Mozilla NSS db in which case object signing might be a possibility.

> If there are two certificates from different CAs in the same database, then
> only one of those CAs is going to be able to have the nickname "$DOMAIN IPA
> CA" set for its certificate.  What's supposed to happen then?
> 
> Installing the same CA certificate with the same nickname, twice, should be
> a no-op, I agree.

Yes, choosing the nickname would be important. I would assume that whatever told certmonger to start tracking would provide the nickname and it would be unique and relevant for the situation. I think this would only be a problem if someone would have to communicate with two different IPA domains named the same thing.

> If we accept that the CA's certificate will eventually be replaced, we need
> to find a way to provide a copy of the replacement certificate to clients
> via an authenticated path.
> 
> We're about to start publishing CA subsystem certificates to the IPA
> directory service.  If we put the CA's signing certificate in there, too,
> then the client would be able to fetch it at any time by performing a
> GSSAPI-authenticated LDAP search.

We've been meaning to do that a while (read years) but haven't gotten around to it. I opened IPA ticket https://fedorahosted.org/freeipa/ticket/2930 for this.

*** Bug 817405 has been marked as a duplicate of this bug. ***

Around 0.75, ipa-getcert's various subcommands should gain a -a flag, which can be used to specify a database to which the CA's certificates should be saved.

Verified

certmonger version:
------------------
[root@dhcp207-1 ~]# rpm -q certmonger
certmonger-0.75.14-2.el7.x86_64
[root@dhcp207-1 ~]# 

snip from automation log:
=========================
:: [   PASS   ]   TC1_getcert_request : Valid location with -F parameter
:: [   PASS   ]   TC2_getcert_request : Invalid location with -F parameter
:: [   PASS   ]   TC3_getcert_request : empty -F parameter
:: [   PASS   ]   TC4_getcert_request : CA already exist in provided file location
:: [   PASS   ]   TC5_getcert_request : Valid nss db location
:: [   PASS   ]   TC6_getcert_request : Invalid nss db location
:: [   PASS   ]   TC7_getcert_request : Empty nss db location
:: [   PASS   ]   TC8_getcert_request : CA already exists
:: [   PASS   ]   TC9_getcert_resubmit : Valid location with -F parameter
:: [   PASS   ]   TC10_getcert_resubmit : Invalid location with -F parameter
:: [   PASS   ]   TC11_getcert_resubmit : empty -F parameter
:: [   PASS   ]   TC12_getcert_resubmit : CA already exist in provided file location
:: [   PASS   ]   TC13_getcert_resubmit : Valid location with -a parameter
:: [   PASS   ]   TC14_getcert_resubmit : Invalid location with -a parameter
:: [   PASS   ]   TC15_getcert_resubmit : empty -a parameter
:: [   PASS   ]   TC16_getcert_resubmit : CA already exist in provided nss db location
:: [   PASS   ]   TC17_getcert_start_tracking : Valid location with -F parameter
:: [   PASS   ]   TC18_getcert_start_tracking : Invalid location with -F parameter
:: [   PASS   ]   TC19_getcert_start_tracking : empty -F parameter
:: [   PASS   ]   TC20_getcert_start_tracking : CA already exist in provided file location
:: [   PASS   ]   TC21_getcert_start_tracking : Valid location with -a parameter
:: [   PASS   ]   TC22_getcert_start_tracking : Invalid location with -a parameter
:: [   PASS   ]   TC23_getcert_start_tracking : empty -a parameter
:: [   PASS   ]   TC24_getcert_start_tracking : CA already exist in provided nss db location

If this Feature should be included in the 7.1 Release Notes, could you please change the Doc Type from Enhancement to "Release Note"?

Note that the Release Notes are intended to list the most prominent and customer-relevant new features rather than every single enhancement.

Cheers,
Jirka

I wouldn't expect it to be called out, since we don't use it in the default IPA installation scenarios.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0437.html