############ Installation ############ There are multiple ways of installing **django-ca**. Each supported installation method has its own quickstart guide: * :doc:`quickstart/docker_compose`: By far the easiest, fastest and most reliable way. * :doc:`quickstart/as_app`: If you want to integrate django-ca into your existing Django project. * :doc:`quickstart/from_source`: If you want to install the project from source (or want to use it as a template for a totally different platform). * :doc:`quickstart/docker`: If you already have web server, database etc. set up or as a template for orchestration platforms such as Docker Swarm. .. _periodic-tasks-explanation: *********************** 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 :ref:`setup periodic tasks manually `. Generate Certificate Revocation Lists (CRLs) ============================================ The :py:func:`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 :ref:`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 :command:`python manage.py generate_crls` with a similar frequency. Generate OCSP responder certificates ==================================== The :py:func:`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 :ref:`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 :command:`python manage.py generate_ocsp_keys` with a similar frequency. Send notification emails about expiring certificates ==================================================== The :py:func:`~django_ca.tasks.notify_watchers` Celery task is responsible for sending notification emails about expiring certificates. If you do not want to send any notifications, you can safely skip this part. Notification emails are sent out based on :ref:`CA_NOTIFICATION_DAYS `. To send notifications for an expiring certificate, a watcher needs to be added when signing the certificate or later via the admin interface or the `manage.py cert_watchers` command. If you use **django-ca** as a Django app and do not want to use Celery, execute :command:`python manage.py notify_expiring_certs` at least daily, preferably every six hours. Clean up ACME database records ============================== The :py:func:`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 :ref:`CA_ENABLE_ACME `. .. _http-explanation: **************** 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 :ref:`ca-example-crlDistributionPoints` and :ref:`ca-example-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.