Command-line interface¶
django-ca provides a complete command-line interface for all functionality. It is implemented as subcommands of Djangos manage.py script. You can use it for all certificate management operations, and Certificate authority management is only possible via the command-line interface for security reasons.
Note
How you invoke manage.py differs depending on how you installed django-ca. Refer to the installation guide you followed for further instructions.
In general, run manage.py without any parameters for available subcommands:
$ python manage.py
...
[django_ca]
cert_watchers
dump_cert
dump_crl
...
Creating Certificate Authorities and managing Certificates is documented on individual pages:
Index of existing commands¶
manage.py subcommands for certificate authority management:
Command |
Description |
---|---|
|
Write the CA certificate to a file. |
|
Edit an existing certificate authority. |
|
Import an existing certificate authority. |
|
Create a new certificate authority. |
|
List currently configured certificate authorities. |
|
View details of a certificate authority. |
manage.py subcommands for certificate management:
Command |
Description |
---|---|
|
Add/remove addresses to be notified of an expiring certificate. |
|
Dump a certificate to a file. |
|
Import an existing certificate. |
|
List all certificates. |
|
Send notifications about expiring certificates to watchers. |
|
Revoke a certificate. |
|
Sign a certificate. |
|
View a certificate. |
Miscellaneous manage.py subcommands:
Command |
Description |
---|---|
|
Write the certificate revocation list (CRL), see Host a Certificate Revocation List (CRL). |
|
Write an OCSP index file, see Run a OCSP responder. |
Names on the command-line¶
The most common use case for certificates is to issue certificates for domains. For example, a certificate for “example.com” is valid for exactly that domain and no other. But certificates can be valid for various other names as well, e.g. email addresses or URLs. Those names also occur in other places, like in the Name constraints extension for CAs.
On the command-line, django-ca will do its best to guess what you want. This example would issue a certificate valid for one domain and and one email address:
$ python manage.py sign_cert --alt example.com --alt user@example.net ...
If the name you’re giving might be ambiguous or you just want to make sure that the value is interpreted correctly, you can always use a prefix to force a particular type. This is equivalent to the above example:
$ python manage.py sign_cert --alt DNS:example.com --alt email:user@example.net ...
Valid prefixes right now are:
Prefix |
Meaning |
---|---|
|
A DNS name, the most common use case. |
|
An email address (e.g. used when using S/MIME to sign emails). |
|
An LDAP-style directory name, e.g. |
|
A URI, e.g. https://example.com. |
|
An IP address, both IPv4 and IPv6 are supported. |
|
A “Registered ID”. No real-world examples are known, you’re on your own. |
|
Anything not covered in the above values. Same restrictions as for RID apply. |
Wildcard names¶
In some cases you might want to use a wildcard in DNS names. The most common use cases are “wildcard certificates”, which are valid for all given subdomains. Creating such certificates is simple:
$ python manage.py sign_cert --alt *.example.com ...
IP addresses¶
Both IPv4 and IPv6 addresses are supported, e.g. this certificate is valid for localhost
on both IPv4 and
IPv6:
python manage.py sign_cert --alt ::1 --alt 127.0.0.1 ...