Table of Contents
Table of Contents
Explicit testcases are not very common for Open Source projects. There is only a very small number of projects which perform standardized tests. One example is OpenSSL. Nevertheless it is the only way to test software systematically and this absolutely necessary for security relevant systems.
Testcases are good source of documentation because they also describe how a function should work and a user can understand what a developer wants. So testdocuments itself can produce good feedback from users. They made it much more easier for people to evaluate the software because they can compare their requirements with our checklists.
This document is not a simple checklist which you can take, make several check marks and then you know that all is working fine. We support several backend databases and you have to perform all checks for every single supported database backend. So if you start verifying OpenCA with this document then please use the database backend which you use in your production environment.
If there is a new upcoming major release and somebody checks the release then please write small document which lists the performed tests and the results to allow fast bugfixing. Please don't fix bugs for yourself and don't publish the patches. In the past there are several users which fix some problems and never report it. The result was that several people independtly fixed the same bug. This is wasted time and results in badder quality because the result of a bugfix which was revisited by several people is much better then dozens of individuals fixes.
Why does there be an extra security part? Because we need a central point were we can document security issues like key checking and attack scenarios. It is also a first point were you can start defining the security of the CA.
It is also the place to describe common security problem with PKI software which you found. This avoid that we do the same mistake twice.
How does the document be continued? Really simple - if you miss something then write it down and send it to us (openca-users@lists.sf.org). This is the best way to extend such documents. If you are user and you need a feature then write down a testdescription. We integrate into our testcases and if the test fails then it is a bug.
Generally it is a good idea to write down testspecifications for your PKI. If you have trouble with OpenCA then send us the problematical specification and we can think and discuss about the problems. The major goal is to integrate such specifications into our test documents.
Developers should think about tests if the finish a software part and write down at minimum some basic tests. This is much easier then to discuss over design flaws ;-)
Table of Contents
Table of Contents
This chapter should test the installation process for every possible configration. Like usual this is not possible. So if somebody find a configuration which doesn't work then please write a general testconfiguration which creates the error and we add it to this document.
Table of Contents
Table of Contents
Table of Contents
This do the core intitialization of the CA. Here we create a database, the private key and perhaps a self-signed cert. If this phase is complete then there is full operational CA.
All other steps are used to made the CA more usable by helping with the steps but phase I is a MUST for every new OpenCA system except of imports from other CAs.
Table of Contents
Table of Contents
Table of Contents
Table of Contents
Table of Contents
Table of Contents
Table of Contents
Table of Contents
Table of Contents
Table of Contents