Example E.11. virtual host configuration
<VirtualHost _default_:443> ServerName 157.159.100.42:443 ServerAdmin pascal.verrecchia@int-evry.fr DocumentRoot /srv/ra/apache/htdocs ErrorLog /usr/local/apache/logs/error_log Options MultiViews Indexes Fol ................ ........... </VirtualHost>
BindAddress Your_address_IP:80 Listen 80
Example E.12. ./configure and virtual hosts
--with-ca-htdocs-url-prefix=http://ca.dskt6807.zhwin.ch \ --with-node-htdocs-url-prefix=http://node.dskt6807.zhwin.ch \ --with-ra-htdocs-url-prefix=http://ra.dskt6807.zhwin.ch \ --with-ldap-htdocs-url-prefix=http://ldap.dskt6807.zhwin.ch \ --with-pub-htdocs-url-prefix=http://pub.dskt6807.zhwin.ch \
Yes, it is possible. There is an option LDAPexcludedRoles in the configuration files of the node and the ldap interface. If you add a role there then all certificates which have this role will not be published via the LDAP server.
Example E.13. Client authentication with mod_ssl
<VirtualHost ra.mycompany.de:4443> ServerName ra.mycompany.de DocumentRoot /RA/apache/htdocs ServerAdmin nicolaie.szabadkai@mycompany.de SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 SSLEngine on SSLCertificateFile /RA/ssl.crt/server.pem SSLCertificateKeyFile /RA/ssl.key/key.pem SSLCertificateChainFile /RA/OpenCA/var/crypto/chain/cacert.crt SSLCACertificateFile /RA/OpenCA/var/crypto/cacerts/cacert.pem SSLCARevocationFile /RA/OpenCA/var/crypto/crls/cacrl.pem SSLVerifyClient require SSLVerifyDepth 10 SSLOptions +StdEnvVars +ExportCertData +StrictRequire ErrorLog /var/log/httpd/ra.srv.err.log CustomLog /var/log/httpd/ra.srv.req.log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" ScriptAlias "/cgi-bin/" "/RA/apache/cgi-bin/" <Directory "/RA/apache/cgi-bin"> AllowOverride None Options FollowSymLinks Order deny,allow Deny from all Allow from 10.1.114 10.100.1 10.1.102 SSLRequireSSL SSLRequire ( %{SSL_CLIENT_S_DN_O} eq "MyCompany" \ && %{SSL_CLIENT_S_DN_CN} =~ m/ramanager?/ ) </Directory> ... </VirtualHost>
It is necessary that you update your OpenCA installation from time to time. This can happen if there is a new security advisory or some normal bugs are fixed. Since OpenCA 0.9.1 there are bugfix releases. These releases only update the software. They never touch the configuration. If you have a 0.9.1.3 and you have to update to 0.9.1.4 then simply use the same configuration like for 0.9.1.3. The installation with make never overwrites the etc or var area of your already existing installation. Nevertheless it is strongly recommended to backup your complete installation before you start such critical operations like an update.
There are two general methods. You can use backup/restore or you add the columns by hand.
Create a backup from the database with the node interface.
Remove all tables and sequence generators.
Update OpenCA.
Go to the node interface.
Initialize the database.
Go to the recovery page of OpenCA.
Import the database.
Restore OpenSSL's files.
Login to the database.
alter table request add scep_tid TEXTTYPE; alter table log add scep_tid TEXTTYPE; alter table request add loa TEXTTYPE; alter table certificate add loa TEXTTYPE; alter table crr add loa TEXTTYPE; alter table log add loa TEXTTYPE;
Table E.1. Texttypes for different databases
Database | type |
---|---|
mysql | TEXT |
Pg | text |
DB2 | long varchar |
Oracle | varchar2 (1999) |
Go to the node interface.
Administration.
Databasehandling.
Update searchable attributes.
Example E.14. OCSP configuration for LDAP
[ OCSPD_default ] .... dbms = ocsp_crl [ ocsp_crl ] crl_url = ldap://my.ldap.server crl_entry_dn = cn=MyCA,ou=CA,o=MyOrg,c=MyCountry
Example E.15. OCSP configuration for http
[ ocsp_crl ] crl_url = http://my.ca-public.server crl_entry_dn = /crl/cacrl.crl
Before you run configure with the changed config.xml for the second public interface you have to reduce the scope of the files in configure_etc.sh to the new interface.
After such a crash you can configure config.xml to the old values, set the paths in configure_etc.sh to the first interface only (!!!) and then run configure_etc.sh again.
Please read the notices about SMTP servers in the OpenSSL section of the administration guide. If you only have one certificate for your mailserver then it must include the extensions for SSL servers and SSL clients. The extensions for SSL servers are not enough because SMTP servers act as clients too.
There are some situations where clients hang after they try to connect to a TLS or SSL secured server. Examples are Microsoft Outlook clients which connect to mail servers which use TLS or Microsoft Internet Explorers which try to connect to a https server.
Usually the certificate contains a CRL distribution point (CDP) which uses https or ldaps as protocol. The result is that the client tries to verify the server certificate and opens a connection to the server which stores the CDP. If this server presents a certificate which contains a CDP with TLS protection then you have a perfect loop. This can also happen if you try to verify a client certificate which includes a TLS or SSL secured CRL distribution point.
There are two solution for this problem. First you can use only http and ldap or other supported protocols for CRL distribution which don't use TLS and SSL. This is not a big security risc because CRLs are protected by the signature of the corresponding CA. Second you use https or ldaps for client certificates but http or ldap for server certificates. This will produce only one loop if the server certificate will be verified.
If you already enrolled an infrastructure and now you are running into problems with hunderds or thousands of client certificates then you should use the second option to solve your problems. If you enroll new certificates for the servers then you have no problems with your endusers - you have not to explain the problems, the installation of new certificates and the reasons why you don't expect such problems. You “only” install some new server certificates and all problems are fixed like a simple network problem.
The CDP of the certificate from the signature points to a SSL-secured website which was signed by the same CA than the mail certificate. Best solution: Change the CDP to non-https url or a https-url signed by another CA and reissue the mail certificates. If you dont want to reissue all your mail certs it's ok to just change the webservers CDP URL and reissue the webserver certificate.
Old versions of OpenCA include a hardwired minimum length for HTML-textfields. The minimum length was three. You can change this limit in basic_csr. New versions of OpenCA can be configured. Please read the “installation and configuration guide” Section 4, “CSRs”.
Yes, please check etc/config.xml. There are two options menu_logo_left and menu_logo_right which can be used to place logos in the menuframe. Please be careful with this feature because it can reduce the usability of the software.
If you enroll a certificate and a private key to a user via file in PKCS#12 format then you usually want to include the complete certificate chain. This is necessary because many software products doesn't work if the chain is incomplete. This can be normal mail programs or VPN clients. The price is no argument in this case.
Otherwise there can be problems if you try to install certificates which are already present at the target system. The worst case is the destruction of already exeisting certificate chains by overwriting an old CA certificate. Therefore OpenCA only includes the CA certificate which issued the enrolled certificate. Nevertheless it is possible to include as many certificate as you want.
Go to OPENCADIR/lib/cmds
my $cacert = getRequired ('....
my $cacert = "/my/openca/dir/var/crypto/cacerts/blaine.pem";
The next step is to create an individual file for the chain. Now you have to create the file blaine.pem. This file has to include all needed CA certs in PEM format. Please remember to include a begin and end line before and after every CA certificate like for every normal PEM-formatted CA certificate.
If you get an errormessage which indicates that there was an unknown login configured then please see Section 3.7, “Conflicting Modules”.
If you get an error message that OpenCA cannot initialize the cryptoshell and after the startup no daemon is up - wether the XML cache nor the OpenCA daemon then you have perhaps uncleanly stopped OpenCA's daemons. Please check OPENCADIR/var/tmp/ for any socket files. If OpenCA was killed during shutdown without an explicit shutdown by openca_rc or openca_stop then the still existing socketfiles can block the startup of the daemons. This behaviour is a must to avoid implicit killed daemons if you try to start your daemon twice.