1:24 p.m.
Hi Erwin,
I appreciate your response.
The primary reason for wanting to a PKI was to alleviate all the
self-signed certs that we are/will be using. Then I realized that it
could be expanded to include user authentication to our NOC web sites.
So this is how it has evolved.
Currently, I have a primary CA with a secondary CA.
* The primary CA is all hosted on a single host, host A, including
LDAP storage.
* The secondary CA is all hosted on a single host, host B, including
LDAP storage.
* The 2 LDAP servers are in a multi-master config with replication
agreements for the User database, not the CAs though.
* I will create all the certs from the secondary CA.
* We will create user certs
* We will create server certs
* Both hosts are in a 2-node corosync cluster.
So we have numerous single points of failure in this setup, hence my
questions. With I think of HA for this project, I think more along the
lines of availability and less about performance. I have 2 physical
hosts to work with, along with fibre channel with an OCFS2 volume
available to both hosts.
So I would think that what I am looking for is that all services could
be running on a single host, in case the other host failed. Dogtags
supports cloning and so for each service that I need (CA1,CA2, OCSP ), I
can use cloning with manual assistance. I just designate one of host A
or B to be the primary host for a given service. Them clone them to the
other host.
Thanks,
Dave
On 02/17/2011 11:42 AM, Erwin Himawan wrote:
Hi Dave,
Since PKI is so much flexible, your PKI architecture would be
influenced by many factors such as number of subscribers, the
diversity of your subscribers PKI needs, real time access, initial and
operating cost, etc. Also, when you mentioned "HA", what kind of
"HA"
it is; e.g. HA for obtaining new cert, renewal cert, obtaining the
latest revocation status information? HA for certificate publication
in the repository? HA for CA access to the repository? What is the
requirement in your PKI CP?
Not knowing these factors are, it would be very difficult to come up
with the "best" "HA" design for your circumstances.
Regards,
Erwin
On Wed, Feb 16, 2011 at 10:15 PM, Dave Augustus
<davea(a)ingraftedsoftware.com <mailto:davea@ingraftedsoftware.com>> wrote:
We are in the planning stages of deploying a CA using dogtags.
Here is what we know we need and what resources we have to work
with. Any suggestions are welcome!
A primary CA - only used to create the subordinate CAs.
A subordinate CA - this would actually create the certs.
We have 2 servers with shared fiber channel storage. Each
currently has LDAP (389 project) installed and are replicating
between themselves. The LDAP servers run on their own IPs. Also,
these 2 servers are a corosync cluster with 4 resource groups:
puppet, mysql, apache, snmptrapd and syslog-ng. Each of these have
their own IP as well. None of these services are load-balanced.
They are either on one or the other servers- all the files these
services need are supported with fibre channel storage.
Now the CA. Here is what I have considered:
1) CA1 runs on server1- it uses the local LDAP server for storage
2) CA2 runs on server2- it uses the local LDAP server for storage
3) A clone of CA1 runs on server2 using server2's LDAP storage
4) A clone of CA2 runs on server1 using server1's LDAP storage
Ideally, we would run the service like we do apache. It would run
on either host, but only one a time. It would have its files on
shared storage to support this. The problem with this setup is the
LDAP storage is the single point of failure as I cannot refer to 2
LDAP servers at the same time, afaik.
For HA, it seems that the best I could do would be to have both
LDAP servers and all 4 PKI instances installed on shared storage.
Any thoughts on this are greatly appreciated.
Thanks,
Dave
_______________________________________________
Pki-users mailing list
Pki-users(a)redhat.com <mailto:Pki-users@redhat.com>
https://www.redhat.com/mailman/listinfo/pki-users
5054
days inactive
5054
days old
0 comments
1 participants
participants (1)
-
Dave Augustus