Michael Bell wrote:
Nuno Miguel Neves wrote:
OK. After thinking, the scenario is roughly this:
I have an offline CA machine. I have a "major" RA Server (n.1) Then I have 7 different "minor" RA Servers (n.2 to n.8).
I want each "minor" server to have a local database and no knowledge of the others.
Than I want "major" RA server to have a local DB, but be able to import and export data to/from the other RA. Mainly, if the RA Operator on RA fails to accept a request, I will "learn" about it at RA n.1 and sign it there.
Also, RA Server n.1 exchanges data with the other RA, and then it is the only one to exchange data to the CA.
Is this possible?
Yes, this was the idea behind the dataexchange. The problem is the idea of the failing RA operator because there must be a state when the request will be exported. There are two solutions for this problem:
1. The local operator remove the request and you export deleted requests too. On the major RA you can renew and handle the request. The major problem is that this renewal is a little bit poblematical because the key of a renewed request is not checked.
2. You access the problematical request on the minor RA.
Can you give some help in configuring each one in this setup?
Yes, first you must know at which state you want to export a request and at which state it should be handled on which node. A request can have the following states:
NEW RENEW PENDING APPROVED ARCHIVED DELETED
You need the following configuration for the solutions:
1.
CA CSR enrollment: ARCHIVED DELETED CA CSR receiving: APPROVED DELETED major RA CSR enrollment: ARCHIVED DELETED major RA CSR uploading: APPROVED DELETED major RA CSR receiving: APPROVED DELETED major RA CSR downloading:ARCHIVED DELETED minor RA CSR uploading APPROVED DELETED minor RA CSR downloading:ARCHIVED DELETED
2.
CA CSR enrollment: ARCHIVED DELETED CA CSR receiving: APPROVED major RA CSR enrollment: ARCHIVED DELETED major RA CSR uploading: APPROVED major RA CSR receiving: APPROVED major RA CSR downloading:ARCHIVED DELETED minor RA CSR uploading APPROVED minor RA CSR downloading:ARCHIVED DELETED
I would recommend the second solution. The central RA is only a collector in this case.
Michael
I agree that the second solution is the best. However, some details I need help on:
1- The central RA can also have requests and approvals in his own DB, right? From a user point of view, it's just like any of the others, right?
2 - When I configure the dataexchange, using scp, I must copy seven tar files (openca-1.tar, openca-2.tar,...) , one from each minor RA. How do I write the script to read all seven files? And how do I know what to export for each of them?
Thanks,
--
[EMAIL PROTECTED] Dept. Informatica, Fac. Ciencias,
|\ | |\ | Tel: +351 21 7500528 Univ. Lisboa, Bloco C5, Campo Grande
| \|uno | \|eves Fax: +351 21 7500084 1700 Lisboa, Portugal
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Openca-Users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-users
