If you are referring to my input, I mean instances.<br><br>I'm having difficulty following your question about CA-DRM communication, though. Typically, the enrollment pages of a CA are configured with a transport cert known to the DRM to enable the archival. Multiple DRMs can be configured with the same transport cert, if that is what you are getting at.<br>
<br>mrb<br><br><br><div class="gmail_quote">On Wed, Sep 14, 2011 at 4:01 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000">
When we say "one CA" or Multiple "DRM" are we talkin servers?
With Directory Server Replication, I would assume that A CA could
talk to any DRM instance of a replicated group of Directory
Servers? Is this not the case?<div><div></div><div class="h5"><br>
<br>
<br>
<br>
On 09/14/2011 03:33 PM, Michael Brown wrote:
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">On Wed, Sep 14, 2011 at 2:53 PM, Andrew
Wnuk <span dir="ltr"><<a href="mailto:awnuk@redhat.com" target="_blank">awnuk@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On 09/14/2011 10:41 AM, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/14/2011 01:37 PM, Andrew Wnuk wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/14/2011 10:18 AM, Chandrasekar Kannan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/14/2011 10:00 AM, Andrew Wnuk wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/14/2011 09:10 AM, Chandrasekar Kannan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/14/2011 08:42 AM, Andrew Wnuk wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/14/2011 05:31 AM, Chandrasekar Kannan
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/13/2011 05:48 PM, Andrew Wnuk wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/13/2011 06:41 AM, Adam Young wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The Layout of the PKI project is very
unusual for a Java Server application.<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm trying to understand the rationale
for some of the things that were done.<br>
<br>
Why do we create a separate server
instance for each subsystem?<br>
</blockquote>
<br>
Because each subsystem is a standalone
server.<br>
</blockquote>
<br>
I'm not sure if it needs to be a stand alone
server. It was designed and implemented as
such<br>
starting 10 years ago. It might be very well
be a separated name space uri inside the
same tomcat instance.<br>
</blockquote>
<br>
They are standalone servers for reliability
and availability reasons, so single tomcat
failure is not going to knock down all your
servers at the same time.<br>
</blockquote>
<br>
That is easily avoided by cloning...<br>
</blockquote>
<br>
Standalone servers are even more reliable with
cloning. They are more modular and provide bigger
flexibility in designing deployments. For example,
ratio 1:1 between CAs and DRMs is not necessarily
the best as we learned from big deployments.<br>
<br>
(sorry, I missed "not" in the original answer)<br>
</blockquote>
<br>
As we know being modular provides flexibility _only
at a cost_. The cost of deploying more and more
instances is high and having to maintain them as
well.<br>
Rather consolidating these "services" into one
server seems like a good approach to me. When we
start talking about 1:1, I start thinking along
these lines..<br>
<br>
- What good can a DRM do when its associated CA is
offline anyways - it cant archive. So there goes 50%
of its functionality..<br>
- What good can a TPS do when its 1:1 associated
services like tks,drm are offline. Might as well be
a single server.<br>
- What good can a OCSP be when its associated CA is
offline. Serve OCSP requests based on stale data?.<br>
</blockquote>
<br>
Redundancy is the only thing that can help If some
subsystems are permanently offline.<br>
Deployments should be able to recover from situations
where subsystems are temporarily offline.<br>
Please open bugs if there are any issues in the
recovery process.<br>
</blockquote>
<br>
When you say "For example, ratio 1:1 between CAs and
DRMs is not necessarily the best as we learned" what is
the general approach that we have found works?<br>
</blockquote>
<br>
</div>
</div>
It might be hard to define single general approach. Deployment
life is complex combination of many factors starting from
initial architecture, its evolution, real life requirements,
support, environmental limitations, longevity of the
deployment, and budgetary limitations.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> More
DRMS? More CAs?<br>
</blockquote>
<br>
Please ask Michael Brown for more details.</blockquote>
<div><br>
<br>
The largest Red Hat PKI customer has found that multiple CAs
per DRM has worked for them. Not every CA archives keys to a
DRM in the customer deployment, and those that do archive
(several per production site) typically archive to single DRM
or small set of DRMs; smaller than the set of CAs. This is
contrary to how Red Hat has typically documented a deployment
in the Admin Guide, etc., which is one RA to one CA to one
DRM. Also one TPS to one TKS to one CA to one DRM in a Token
deployment, particularly as related to TPS. The customer has
commented on several occasions, sometimes loudly, that this
one-to-one-to-one doesn't reflect the reality of an enterprise
deployment that requires redundancy and availability, and in
which certificate requests are load balanced across a set of
multi-site CAs. I think that's what Andrew has been getting
at above. Maintaining the ability to separate out the
instances will remain important for Red Hat's largest PKI
customer going forward. At the same time, not every customer
deployment will have the same stringent reliability and
availability requirements as the largest customer. <br>
<br>
What I don't see discussed much, either above or in the docs,
is the important role multi-mastered internal slapd servers
can potentially play in providing improved reliability and
availability. These are the main data repositories, and
having these multi-mastered across multiple hosts with
failover is the being seen as the target architecture of
choice for the largest customer going forward (I'm working on
this). Having multiple CA tomcat instances on a single host,
or having multiple DRM tomcat instances on a single host
(separate from the CA hosts) is not seen as a major issue.
The important thing is to be able to re-connect tomcat
instances with the data in a failure. Cloning will also
hopefully be introduced in the next deployment (I'm working on
this), and it will obviously also be a requirement to have
these clones as separate instances, and probably on separate
hosts, to prevent the issue Andrew mentioned above; the
failure of a single tomcat instance taking out multiple
instances of CA, DRM, etc.<br>
<br>
Hope this helps.<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>
<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
IMHO this modular design has brought in unnecessary
complexity to a PKI topology which could be
simplified by consolidating these services together
in a single container.<br>
</blockquote>
</blockquote>
</blockquote>
</div>
</div>
</blockquote>
<div><br>
<br>
Do you have a suggested topology that will be simpler and also
meet the requirements of Red Hat's largest customer?<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>
<div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is a reason to continue doing so?<br>
</blockquote>
<br>
It provides great flexibility in deploying
Certificate Server<br>
</blockquote>
<br>
The same level of flexibility can be
achieved even with a single tomcat instance
provided that instance configuration at
install time takes care of tweaking stuff.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is using different ports for CA and DRM
(an so forth) merely an artifact of
using multiple servers, or is there an
additional reason to do so?<br>
</blockquote>
<br>
Pkicreate tool allows selecting any ports.
Pkicreate also suggests ports for out of
the box ease of use.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Do we expect the same user to have and
user different certificates for
different servers,<br>
</blockquote>
<br>
This is a matter of deployment strategy.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
such that the certificate then becomes a
union of authentication and
authorization?<br>
</blockquote>
<br>
Certificates are the source of identity.
Authorization is a separate process based
on verified identity.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is there a reason to separate the CA
and DRM Directory servers?<br>
</blockquote>
<br>
Protection of archived keys.<br>
</blockquote>
<br>
They could even stay protected - if there's
a plan to consolidate.<br>
In my mind Separation != protection.<br>
</blockquote>
<br>
Separation is not equal protection, but it
allows to apply appropriate protection
standards to specific data.<br>
</blockquote>
<br>
I'm yet to hear how it cannot be achieved
otherwise when consolidated..<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Is it a
"best practice" to do so? What would be
the implications of using a single
instance for both?<br>
<br>
Is there any reason why the CA uses an
LDAP server instead of a Relational
Database?<br>
</blockquote>
<br>
X509 certificates are using the same
distinguished names as LDAP.<br>
Many identity products are based on
directories.<br>
Provides very secure access options.<br>
Provides robust replication over secure
channel.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Do we
expect people to make queries dircetyl
against the CA DirSrv,<br>
</blockquote>
<br>
No<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
or is the Database best hidden from
public view?<br>
<br>
Why do we split the build process up
into multiple Source RPMS?<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Is there
a reason to maintain this split?<br>
<br>
Are there design documents or
discussions for these decisions?<br>
</blockquote>
<br>
Yes, please look for "Legacy Certificate
Management System Website" on the internal
CS wiki.<br>
</blockquote>
<br>
Sorry I dug through that pile. None answered
the first question still so far for me. Why
are these separate instances to begin with
?.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
_______________________________________________<br>
Pki-devel mailing list<br>
<a href="mailto:Pki-devel@redhat.com" target="_blank">Pki-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a><br>
</blockquote>
<br>
_______________________________________________<br>
Pki-devel mailing list<br>
<a href="mailto:Pki-devel@redhat.com" target="_blank">Pki-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a><br>
</blockquote>
<br>
</blockquote>
<br>
_______________________________________________<br>
Pki-devel mailing list<br>
<a href="mailto:Pki-devel@redhat.com" target="_blank">Pki-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a><br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
_______________________________________________<br>
Pki-devel mailing list<br>
<a href="mailto:Pki-devel@redhat.com" target="_blank">Pki-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a><br>
</blockquote>
<br>
_______________________________________________<br>
Pki-devel mailing list<br>
<a href="mailto:Pki-devel@redhat.com" target="_blank">Pki-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
Pki-devel mailing list<br>
<a href="mailto:Pki-devel@redhat.com" target="_blank">Pki-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Pki-devel mailing list
<a href="mailto:Pki-devel@redhat.com" target="_blank">Pki-devel@redhat.com</a>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Pki-devel mailing list<br>
<a href="mailto:Pki-devel@redhat.com">Pki-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pki-devel" target="_blank">https://www.redhat.com/mailman/listinfo/pki-devel</a><br>
<br></blockquote></div><br>