Cool. And one more inquiry:
-What does the authentication scheme for Gutterball look like (in relation to its use in Katello)

On Tue, Feb 16, 2016 at 12:43 PM, Alex Wood <awood@redhat.com> wrote:
On 02/16/2016 08:39 AM, Lesley Kimmel wrote:
> Can you explain a little how Candlepin generates certificates for
> clients? Does it have a self-signed CA certificate that it uses to
> sign these client certs? Would it be possible (albeit inconvenient)
> to use 3rd part signed certs for these client certs?

Yes, client certificates are signed by a self-signed CA certificate
that is created when Katello is installed.

Candlepin issues two types of certificates: identity certificates and
entitlement certificates.  Identity certificates are issued when a
system registers to Candlepin and are henceforth used when the client
communicates with Candlepin.  Entitlement certificates are issued by
Candlepin when a subscription is used and are presented to the content
delivery network when attempting to install packages from repositories
in /etc/yum.repos.d/redhat.repo.

As for whether it would be possible to use third-party signed
certificates...  That is a good question.  If it is possible, it's
going to be very difficult.  For one, Candlepin is designed to send
the identity certificate and key back in the HTTP response body after
registration.  That certificate and key are kept in escrow in
Candlepin's database (not a practice I am personally a fan of, but
that's the way it's designed at the moment).  As well, the CN of the
identity certificate is a unique identifier that Candlepin assigns.

So while you could modify Tomcat to use a different truststore and
create a third-party signed certificate after the fact using the CN
that Candlepin assigns, the system's record in the Candlepin database
would have an incorrect cert and key.  I don't know off the top of my
head if we ever use the cert and key again, but it doesn't look like
we accept updates to those values via the update consumer method (PUT
/consumers/{consumer_id}).  Additionally, I can't say for certain
whether or not subscription-manager would just overwrite the
third-party signed certificate arbitrarily at some point since the
identity cert it has would be in conflict with what Candlepin returned
in HTTP response bodies.

As for using third party signed entitlement certificates, I think that
would be even harder.  Our entitlement certificates have data embedded
in them as custom certificate extensions.  You would have to pull that
data out and then get it into the CSR for the third party to sign.

Ultimately, I would consider third-party signed certificates to be
impractical to implement.  However, if you are dealing with an
internal CA that you want to sign Candlepin issued certificates, it
might make more sense to have that internal CA create a sub-CA for
Candlepin to use.  That sub-CA would have the path length constraint
set to 0 in the basic constraints section (so that it could not issue
further sub-CAs).  You might also explore the using the
NameConstraints extension to limit the namespaces that the Candlepin
CA could sign (although I believe support and respect for
NameConstraints is generally very poor) [1]

[1]
http://blog.codekills.net/2012/04/08/adventures-in-x509-the-utterly-ignored-nameconstraints/
-----------------
Regards,
Alex


_______________________________________________
candlepin mailing list
candlepin@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/candlepin@lists.fedorahosted.org