Custom settings

You can use any of the settings understood by Django and django-ca provides some of its own settings.

From Djangos settings, you especially need to configure DATABASES, SECRET_KEY, ALLOWED_HOSTS and STATIC_ROOT.

All settings used by django-ca start with the CA_ prefix. Settings are also documented at ca/ca/ (view on git).


Default: []

This setting is only used when you use django-ca as a standalone project to let you add custom apps to the project, e.g. to add Signals.

The list gets appended to the standard INSTALLED_APPS setting. If you need more control, you can always override that setting instead.


Default: "SECP256R1"

The default elliptic curve used for generating CA private keys when ECC is used.


Default: 730

The default time, in days, that any signed certificate expires.


Default: 4096

The default key size for newly created CAs (not used for CAs based on ECC).


Default: webserver

The default profile to use.


Default: {}

The default subject to use. The keys of this dictionary are the valid fields in X509 certificate subjects. Example:

   'C': 'AT',
   'ST': 'Vienna',
   'L': 'Vienna',
   'O': 'HTU Wien',
   'OU': 'Fachschaft Informatik',
   'emailAddress': '',

Default: "sha512"

The default digest algorithm used to sign certificates. You may want to use "sha256" for older (pre-2010) clients. Note that this setting is also used by the init_ca command, so if you have any clients that do not understand sha512 hashes, you should change this beforehand.


Default: "ca/files"

Where the root certificate is stored. The default is a files directory in the same location as your file.


Default: [14, 7, 3, 1, ]

Days before expiry that certificate watchers will receive notifications. By default, watchers will receive notifications 14, seven, three and one days before expiry.


Default: {}

Configuration for OCSP responders. See Run a OCSP responder for more information.


Default: {}

Profiles determine the default values for the keyUsage, extendedKeyUsage x509 extensions. In short, they determine how your certificate can be used, be it for server and/or client authentication, e-mail signing or anything else. By default, django-ca provides these profiles:

Profile keyUsage extendedKeyUsage
client digitalSignature clientAuth
server digitalSignature, keyAgreement keyEncipherment clientAuth, serverAuth
webserver digitalSignature, keyAgreement keyEncipherment serverAuth
enduser dataEncipherment, digitalSignature, keyEncipherment clientAuth, emailProtection, codeSigning
ocsp nonRepudiation, talSignature, keyEncipherment OCSPSigning

Further more,

  • The keyUsage attribute is marked as critical.
  • The extendedKeyUsage attribute is marked as non-critical.

This should be fine for most usecases. But you can use the CA_PROFILES setting to either update or disable existing profiles or add new profiles that you like. For that, set CA_PROFILES to a dictionary with the keys defining the profile name and the value being either:

  • None to disable an existing profile.

  • A dictionary defining the profile. If the name of the profile is an existing profile, the dictionary is updated, so you can ommit a value to leave it as the default. The possible keys are:

    key Description
    "keyUsage" The keyUsage X509 extension.
    "extendedKeyUsage" The extendedKeyUsage X509 extension.
    "desc" A human-readable description, shows up with “sing_cert -h” and in the webinterface profile selection.
    "subject" The default subject to use. If ommited, CA_DEFAULT_SUBJECT is used.
    "cn_in_san" If to include the CommonName in the subjectAltName by default. The default value is True.

Here is a full example:

    'client': {
        'desc': _('Nice description.'),
        'keyUsage': {
            'critical': True,
            'value': [
        'extendedKeyUsage': {
            'critical': False,
            'value': [
         'subject': {
            'C': 'AT',
            'L': 'Vienna',

     # We really don't like the "ocsp" profile, so we remove it.
     'ocsp': None,

Default: True

If set to False, django_ca.urls will not add a CRL view. See Use generic view to host a CRL for more information.

This setting only has effect if you use django_ca as a full project or you include the django_ca.urls module somewhere in your URL configuration.