Hello, I take advantage of your email to talk about something I've
experienced in 3 years of OpenCA using and that can be usefull for the new
releases of this package.
There is a very big issue on OpenCA when it is used in situations with more
than 50000 certificates issued. All the commands that has to load all
certificates, in order to complete a procedure, will fail or perform in not
so user friendly ways. I can summarize this situations because they are the
ones I've experienced in this years:
- Issuing or revoking a certificate when you have more than 80000
certificates issued. The main problem are performances, because I've
experienced about 10 seconds to issue a certificate with 100000 certificates
already issued. The cause of this is NOT OpenCA itself, but OpenSSL, in
particular the index.txt handling: OpenSSL for every operation that alters
the index.txt performs always the same steps: it makes a copy of index.txt
(I think to backup it and to defragment it), it reads all the content (i.e.
it parses every row in order to fill its internal structures), it saves the
file and, if I remember well, it makes another copy of it. All those
operations are very heavy because this file, with 100000 certificates
issued, is about 25 megabytes.
- Massively publishing all the certificates on LDAP, with more than 40000
certificates issued. Here there are different problems: the first is that
the web page that shows the operation status goes in timeout. This is caused
by the timeout configured on Apache. The big issue here is that the command
first reads all valid certificates from the database to memory and then it
publishes them on LDAP. If you are lucky and the timeout happens after the
database read operation, then the page will go on timeout but the procedure
will continue, but the user cannot know this because the page is in error.
If the timeout happens while reading from database then the command will not
publish on LDAP. There is also another big problem here: on some
installations the procedure will always fail for an inexplicable problem:
after the command reads all the issued certificates, the function that
converts the single certificate read from the database to the format needed
by the LDAP function, will always fail because... I don't know! :-D The
OpenSSL command line executed doesn't find a temporary file created before
(this happens only after a massive load from the database, not with one
certificate). In this situation, if you higher the timeouts on Apache,
you'll have an LDAP server populated only with entries without
userCertificate attributes.
- Reconstructing the OpenSSL index.txt file with more than 40000
certificates issued. The problem is the same of the LDAP publishing: it is
caused by the massive loading in memory of all the certificates from the
database.
As you can see the problems are scalability related. The OpenSSL problem is
related to the internal "ca application" (it was never intended by the
authors to be used in production with a big number of certificates). This
problem can be resolved only in one way: delete the index.txt before issuing
a certificate, construct an index.txt file at runtime containing only the
certificate to revoke before revoking a certificate, construct an index.txt
at runtime before issuing the CRL with only the revoked and suspended
certificates. But here I don't know if there are problems on multithreading,
only Massimiliano can tell :-)
The other two problems can be resolved only if the massive commands can be
invoked without the web interface, I mean through a command line that has no
timeouts and shows the progres in realtime. Those commands are needed only
in particular situations by expert users (for example if you use OpenCA in a
PKI that has a disaster recovery site). Moreover the procedure can perform
better if it reads the certificates from the database one at a time and
performs the task with it. In the DBI modules I've seen some functions that
has to do with "cursors" and "next" record, they suggest me that something
is possible, but I've not found any usage of them in the code, so I'm not
able to understand how they work (learn by examples :-P ).
Now a thing that is not regarding problems: I've developed another OpenCA
interface that can be used to interact with OpenCA like if it was an engine:
through this interface an external system can issue, revoke, suspend and
reinstate a certificate in an autoenrol manner (without operators
interaction). Moreover the same external system can publish a new CRL (I use
this to make jobs in the crontab and schedule this task locally) and read an
issued certificate from OpenCA. The only prerequisite of this interface is
that OpenCA is installed in the configuration RA-CA on the same machine. The
CA runs like an engine that exposes services in a SOA manner. The external
system invokes, in a request-response way, a new set of commands through the
HTTP protocol on the new interface (the other ones, ra, ca, ldap, etc... are
still working). I can assure that this use of OpenCA, also if it appears not
so secure, is VERY helpful in a multi tier structured PKI (the CA will stay
in the lower layers, the service layer besides the database layer). The main
problem here is that... I'm not able to integrate this changes in the source
tree of OpenCA and make it public! :-( If you want (and if it is useful for
the future releases) I can publish on the ML the source files of the changes
I made on the 0.9.2.2 version in order to integrate it in the next releases.
I'll publish also the other changes in other zones of the code base (mainly
on the LunaCA3, LunaSA and Eracom integration) :-)
Bye for now
On Mon, Aug 18, 2008 at 20:02, Massimiliano Pala <[EMAIL PROTECTED]>wrote:
> Hi Diego,
>
> I would be happy to include your fix into the next official release, please
> send me it as soon as possible :D
>
> Later,
> Max
>
>
>
> Diego de Felice wrote:
>
>> I remember there is a bug in this procedure (lib/cmds/importCACerts) that
>> I fixed some month ago. Sorry, I forgot to post to the mailing list. However
>> now I'm in vacation and I don't have the source code here. If you can wait
>> next week, I can post the patched code. I remember, the problem is in the
>> following line of code:
>>
>> my $ret = `$cmd 2>&1`;
>>
>>
>> because it fails but it returns no error in $ret, so the procedure
>> continues and, in the instruction after, the procedure fails and you obtain
>> the error you see (but it is completely unrelated to the database). I
>> suggest you to check the commands in the conf file contained in the
>> variables IMPORT_EXPORT_LOCAL_IMPORT and _DEVICE in the meantime.
>>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Openca-Users mailing list
> Openca-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openca-users
>
>
--
Diego
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users
