Attachment 832204 Details for Bug 1037717 – ocspd configuration

ocspd configuration

ocspd.conf (text/plain), 10.27 KB, created by Account closed by the user on 2013-12-03 16:21:26 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Account closed by the user

Created: 2013-12-03 16:21:26 UTC

Size: 10.27 KB

patch

obsolete

># OCSPd example configuration file.
># (c) 2001 by Massimiliano Pala - OpenCA Project.
># All rights reserved
>
>[ ocspd ]
>default_ocspd   = OCSPD_default         # The default ocspd section
>
>####################################################################
>[ OCSPD_default ]
>
>dir              = /etc/ocspd   # Where everything is kept
>db               = /var/CA/index.txt
>md               = sha1
>
>ca_certificate    = /etc/ocspd/certs/cacert.pem
>ocspd_certificate = /etc/ocspd/certs/ocspd_cert.pem     # The OCSP server cert
>ocspd_key         = /etc/ocspd/private/ocspd_key.pem    # The OCSP server key
>pidfile           = /var/run/ocspd.pid          # Main process pid
>
># User and Group the server will run as. It is a good idea
># not having servers running as root: in case of errors in
># the code providing an 'illegal' access method for an attacker
># it is better not to give him additional advantages.
>user                    = ocspd
>group                   = ocspd
>
># Bind to a specific address. This option is useful if you need
># to listen only on one IP among the availables ones.
>bind                    = *
>
># Port where the server will listen for incoming requests.
>port                    = 2560
>
># Max size of accepted requests. Data connection will be closed
># in case this size will be reached.
>max_req_size            = 16384
>
># Number of threads that shall be created at startup time, the
># more threads, the better for handling very high traffic. We
># expect to have better performances on multi-threaded machines
># and processors.
>threads_num             = 15
>
># Size of the system listen() queue. This allows buffering connection
># requests for later processing when all threads are already busy.
>#max_client_num         = 30
>
># Max timeout for request receiving. If a request is not received
># within the specified number of seconds then the socket is closed
># in order to free unused threads. If not set, the default value
># is 5 seconds
>max_timeout_secs        = 5
>
># HTTP protocol version to be required. If 1.1 is specified, then
># the "Host: <addr>" name is also used in the header of HTTP GET
># requests
>http_proto              = 1.1
>
># Chroot the application into the specified directory, whatch
># out because if you chroot the application, all the paths
># should be relative to the new root for CRL reloading or
># (better solution) you have to download the CRLs from HTTP or
># LDAP. If you chroot and you do not provide support for
># privileges dropping, privileges will not be dropped and an
># error will be written in the logfile, but the server will
># continue to run assuming the chroot() is sufficiently isolated
># to prevent abuse of the machine.
>#chroot_dir             = /usr
>
># Auto Reload interval of CRL (if set to 0 or not present, to
># reload the CRL you'll need to send a SIGHUP (kill -1 <pid>)
># to the parent process (seconds)
>crl_auto_reload = 3600
>
># Check CRL validity period. If this parameter is set to #n
># then the CRL is checked every #n secs and if the CRL's validity
># period is expired then all the responses will be set to
># 'unknown'.
># If 'crl_check_validity' is set to '0' or it is absent, all
># responses will be based on the loaded CRL, no matter if it
># is expired or not.
>crl_check_validity = 600
>
># Reload CRL if the one loaded is expired. Set this parameter
># only if you are sure that the new CRL will be issued and put
># in the crl_url.
>#crl_reload_expired = yes
>
># Specifies the response section to load the server options
># from
>response        = ocsp_response
>
># It specifies the section to be used where options about where
># CRL and certificates are kept.
>#
># Example section using LDAP for data retrieval
># dbms          = dbms_ldap
>#
># Example section using FILES for data retrieval
>dbms            = dbms_file
>
># Enables the ENGINE interface for the server. If set to off then
># no support for ENGINE is loaded. If set to anything but 'off' the
># value must correspond to a section in this configuration file.
># Currently only LunaCA3, LunaSA are directly supported. If you need
># support for other HSM write to the authors.
>#
># IMPORTANT NOTE: in case of usage with engine support enabled, put
># the private key ID - look at the HSM documentation - into the
># 'ocspd_key' field above in this file
># engine = HSM
>
>####################################################################
>[ ocsp_response ]
>dir                     = /etc/ocspd
>
># It is possible to include additional certificates in given
># responses. Put all the certificates you want to include in
># the file pointed by 'ocsp_add_responses_certs', concatenated
># one after the other.
>#
># Comment this option if you don't want to add certificates
># to responses.
>ocsp_add_response_certs = /etc/ocspd/certs/cacert.pem
>
># Set this option if you want to include the KeyID. If you are
># unsure about this setting, use 'yes'.
>ocsp_add_response_keyid = yes
>
># next_update_days and next_update_mins allows to specify in
># each response when new revocation data will be available.
># If the two options are both set to '0' the 'nextUpdate' field
># in the OCSP response will be left NULL indicating new data
># can be made available anytime (this is true if you are issuing
># new CRLs every time a revocation takes place)
>#
># NOTE: Firefox/Mozilla do not parse correctly the OCSP answer in
># case the nextUpdate field is missing. It is therefore suggested
># to use the next_update_mins set (e.g. 5 minutes) to have mozilla's
># software correctly work with OCSP enabled.
>next_update_days        = 0
>next_update_mins        = 5
>
>
>####################################################################
>[ dbms_ldap ]
>
>0.ca = @ldap_ca_1
>
>[ ldap_ca_1 ]
># You can have the CRL on a simple file
># crl_url = file:///etc/ocspd/crls/crl.pem
>
># You can have the CRL retrieved from an HTTP server
># crl_url = http://[user[:pwd]@]server[:port]/path_to_crl
>
># You can store the CRL into an LDAP server, simply
># store it in certificateRevocationList;binary attribute
>#
># There are different way, all legal, to specify the CRL
># URL address:
># crl_url = ldap://[user[:pwd]@]ldap.server.org[:389]
># crl_url = ldap://ldap.server.org:389
>crl_url = ldap://localhost
>
># The CRL entry DN is the DN to look for when retrieving the
># date from the LDAP server. Put here the complete DN (usually
># the DN of the CA's certificate).
>#
># This option is needed only if the CRL is stored on LDAP
>crl_entry_dn = "cn=Certification Auth, o=Organization, c=IT"
>
># To retrieve the CRL from LDAP the attribute where it is stored is to
># be specified. Usually this should be set to:
>#
>#     certificateRevocationList;binary
>#
># anyway existing LDAP installations or new standards can mandate
># for different attributes for storing CRLs into. Use this parameter
># to specify the attribute used to retrieve the CRL from.
>#
># This option is needed only if the CRL is stored on LDAP
>crl_entry_attribute = "certificateRevocationList;binary"
>
># We need the CA certificate for every CA we support. Upon loading
># the CRL and the CA certificate a simple check is made to ensure
># the CRL/CA certificate matching. Also the CA certificate is used
># to retrieve the CID used to identify the certificate being
># requested by the client (CID of the Issuer + serial Number).
># Like the CRL URL, the URL scheme for the CA may be file, ldap or http.
>ca_url  = ldap://localhost
>
># DN where the cACertificate;binary value can be downloaded
># This option is needed only if the CA Certificate is stored on LDAP
>ca_entry_dn = "o=Organisation, c=IT"
>
># This is the attribute used to store the CA.
>ca_entry_attribute = "caCertificate;binary"
>
># Server Certificate to attach to the response
>server_cert = file:///etc/ocspd/certs/ocspd_cert.pem
>
>####################################################################
>[ dbms_file ]
>
># We can have as many CAs supported as we want, each CRL will be
># loaded and stored upon server starting
>0.ca = @first_ca
>#1.ca = @second_ca
>
>####################################################################
>[ first_ca ]
>
># You can have the CRL on a simple file in PEM format
>#crl_url = file:///etc/ocspd/crls/crl_01.pem
>crl_url = file:///var/CA/crl/cacrl.pem
>
># We need the CA certificate for every supported CRL
>#ca_url  = file:///etc/ocspd/certs/1st_cacert.pem
>ca_url  = file://var/CA/certs/cacert.pem
>
># Server Certificate to attach to the response
>server_cert = file:///etc/ocspd/certs/ocspd_cert.pem
>
>####################################################################
>[ second_ca ]
>
># You can have the CRL on a simple file in PEM format
>crl_url = file:///etc/ocspd/crls/crl_02.pem
>
># We need the CA certificate for every supported CRL
>ca_url  = file:///etc/ocspd/certs/2nd_cacert.pem
>
># Server Certificate to attach to the response
>server_cert = file:///etc/ocspd/certs/ocspd_cert.pem
>
>####################################################################
>[ HSM ]
>
># Setup parameters for basic lunaCA3/LunaSA crypto hardware.
>
># Specifies the ENGINE id to be used - check OpenSSL and your HSM
># vendor to get more info about this parameter.
>engine_id = LunaCA3
>
># Some HSM need initialisation before access to the crypto accelerated
># functions is granted. It is possible, by using the 'engine_pre' options
># to issue needed commands directly to the HSM.
>#
># The format is as follows:
>#    0.engine_pre = cmd:values
>#    1.engine_pre = cmd2:values
>#    ...
># It is possible to have as many commands as needed.
># The following command is for LunaCA3/LunaSA. It forces the vendor's
># library to use '/etc/my_conf_file' as configuration file (check the
># HSM documentation about this file contents.
>#0.engine_pre = CONF_PATH:/etc/my_conf_file
>
># The following is for LunaCA3/LunaSA where the command is 'login' and
># the value is "1:10:11:myPassword" which indicates to use Slot 1,
># high application id 10, low app id 11 and password "myPassword"
>0.engine_pre = login:1:10:11:myPassword
>
># Some HSMs need to perform commands after the ENGINE initialisation
># which are taken from the 'engine_post' option. Usage and format
># is exactly the same as 'engine_pre', the difference is that commands
># are sent to the HSM after the ENGINE_init() function. Refer to your
># HSM documentation for more informations
># 0.engine_post = logout:1:10:11
>

Actions: View

Attachments on bug 1037717: 832204 | 832207