Systems - CAcert Testserver
- Currently, April 2010, the Software-Assessment project deploys a new testserver environment.
The "old" testserver. Nevertheless it currently is considered to be the more important reference system because its intallation is more complete and "closer" to the production server.
More details at SystemAdministration/Systems/Test.
test3 is a new (probably temporary) virtual machine, primarily to test the migration to PHP 7. Mangels verfügbarer IPv4-Adressen müssen alternative Ports verwendet werden:
The testserver environment uses its own root and intermediate certificate, of course. Traditionally the server certificates for test servers (and test managers where applicable) are issued by the test roots themselves. Please do not import/trust the test roots in software/browsers that are also used for the "real world"!.
It is prefeerred that you use a different account or browser profile for testing. If this is not possible or practicable, security exceptions are the method of choice. Of course the latter have to be updated regularly when new certificates for the servers are issued.
Traditionally the CA databases ("index.txt") are re-used even after a change of the root certificate(s). On occasions the next issued serial number ("serial") has been increased, probably to test longer serial numbers.
CA:TRUE constraint is essential, for obvious reasons
Subject Distinguished Name (DN): /C=CH/ST=Geneva/L=Geneva/O=CAcert Inc ***TEST***/OU=Test and Development/CN=CAcert Testserver Root
Details are not critical. It makes sense to match the real life location of CAcert Inc and include the fact that this is some kind of test root, to avoid users to accidentially use it instead of the "real" roots. The organisation should start with CAcert to make it easier to find the certificate in key storages, where this data is usually displayed prominently.
Serial number: Normally this is not critical for the testserver1. Traditionally something low, one or two hex digits.
- Validity: Traditionally 10 years, but shorter lifetimes may make sense in specific circumstances.
- Algorithm: Traditionally 4096 bits RSA
authorityInfoAccess: The OCSP links should be adjusted to the testserver. I'm not sure if this extension makes much sense in the root certificate, AFAIK this is also included in every issued certificate. Looks like it does not hurt.
- crlDistributionPoints: Similar to authorityInfoAccess this should be adjusted to the testserver.
- certificatePolicies: I don't think that it helps to create a testserver specific policy, so this should point at the production policy document.
subjectKeyIdentifier and authorityKeyIdentifier: I'm not sure if these make sense in the root cert, but they don't seem to hurt.
- nsCaPolicyUrl and nsComment are deprecated. So I would not use them.
Class 3 Content/Constraints
Most things are identically to the root certificate, so only the differences are noted here.
Subject Distinguished Name (DN): /C=CH/ST=Geneva/L=Geneva/O=CAcert Inc ***TEST***/OU=Test and Development/CN=CAcert Testserver Class 3
Details are not critical, see above.
In the class 3 certificate the serial number is relevant, since there must be no two (active?) certificates signed by the root certificate with the same serial number. So, traditionally the next serial number of the CA database is used.
Experience from 2021 when creating a new root certificate set
The certificates were created using the attached script NewTestserverRoots, with the two configuration files testserver-root.cnf and testserver-class3.cnf. The tempCA subdirectory did contain a copy of the "database files" (index.txt, index.txt.attr and serial) from the /etc/ssl/CA directory. The copy was used for experimenting, after the "real" run the created (and modified!) files were copied back to /etc/ssl/CA manually.
The created class 3 root was manually renamed and then copied to /etc/ssl/class3/.
Other things to do:
Copy the created certificates to the place where they can be downloaded by http://test.cacert.org/index.php?id=3. That is, to the directory /home/cacert/www/www/certs/, in my case to the files root_0XF.* and CAcert_Class3Root_x14E228.*
The signer's job is to sign certificates and similar things, like CRLs. The private keys for the root certificates are stored on the signer machine only.
In the production environment the signer machine is a different computer which is not connected to any LAN type network2. It is connected with a USB serial connection to the main webserver machine. On this serial line a special protocol is run so the webserver can send signing requests to the signer, to which the signer replies by sending the created certificates.
In the test environment the signer machine normally is emulated as a different process which communicates with the webserver part using pipes3.
The signer process runs in its own directory, located at /home/signer. The signer script itself is located at /home/signer/cacert-devel/CommModule/server.pl. It accesses the OpenSSL configuration files from /etc/ssl/
In the configuration file for the root certificate, the directory /etc/ssl/CA is used for the CA's data (including the private key), and /etc/ssl/class3 for the intermediate root. (ToDo: What is the class3s configuration which points at /etc/ssl/class3s? This directory is not present on the testserver...)
client.pl runs in its own process in background and handles the following jobs:
reads certificate requests from the database4
- creates "sanitized" CSR files for signing by server.pl by mixing data from the database and the uploaded CSR files
- transmits the CSR to server.pl via "serial line" and fetches results from server.pl
- sends revocation requests to server.pl and fetches the resulting updated CRL
If client.pl is modified the background process must be restarted before the changes become active. Look for a process /usr/bin/perl -w /home/cacert/www/CommModule/client.pl and kill it. It should be immediately be restarted by the deamon /home/cacert/www/CommModule/commdaemon .