Installation

There are multiple ways of installing django-ca. Each supported installation method has its own quickstart guide:

Required periodic tasks

django-ca requires a few tasks to be run periodically.

If you chose an installation method that includes the full Django project (e.g. using Compose, Docker or from source), everything is already set up for you and you can skip this section entirely, unless you want to mess with some very specific settings.

If chose to use django-ca as a Django app, you have to setup periodic tasks manually.

Generate Certificate Revocation Lists (CRLs)

The django_ca.tasks.generate_crls() Celery task is responsible for generating CRLS. By default, the Celery task is run a bit less then once a day.

CRLs expire after one day and are renewed after twelve hours by default, but this can be changed via CA_CRL_PROFILES. If you change this setting, the frequency of this task should be at least (expires - renewal) / 2 (e.g. with the default “24 hours - 12 hours / 2” at least every six hours) to make sure that the CRL is renewed in time.

If you use django-ca as a Django app and do not want to use Celery, execute python manage.py generate_crls with a similar frequency.

Generate OCSP responder certificates

The django_ca.tasks.generate_ocsp_keys() Celery task is responsible for generating OCSP keys. By default, the Celery task is run every hour.

Certificates are not renewed unless they expire within the interval defined by CA_OCSP_RESPONDER_CERTIFICATE_RENEWAL. If you change that setting, the frequency of this task must be higher then that setting.

If you use django-ca as a Django app and do not want to use Celery, execute python manage.py generate_ocsp_keys with a similar frequency.

Clean up ACME database records

The django_ca.tasks.acme_cleanup() Celery task is responsible for cleaning up database entries related to ACME operations, e.g. expired ACME orders. The task runs every five minutes by default.

This task is not required if you have disabled ACME via CA_ENABLE_ACME.

Why plain HTTP?!

OCSP and CRL access (protocols used to obtain the revocation status of certificates) usually work via HTTP, not HTTPS. Clients would need to obtain the revocation status of the certificate used for the HTTPS connection using that same HTTPS connection. Responses are signed, so using HTTP is not considered a security vulnerability.

Just in case you doubt the above: check how publicly trusted and widely used certificate authorities set the CRLDistributionPoints and AuthorityInfoAccess extensions.

However, only CRL, OCSP and issuer information needs to be available via HTTP. If you use /ca as path in your URL configuration (like in the example above), you only need /ca/issuer/, /ca/ocsp/ and /ca/crl/ available via HTTP.