<commit_before>Certificate Authority (CA) and certificate how-to
-------------------------------------------------

As of burp-1.3.2, the process of generating SSL certificates has been
automated.

Effectively, the automation means that you can set up a new client on the
server (in /etc/burp/clientconfdir/<client>), and the first client to connect
that matches that client name and password will get its certificate signed
and given back. If a different, second client, happens to connect with the
same client name and password, it will be rejected because it doesn't have
a matching certificate.


Server CA options:
ca_conf = /etc/burp/CA.cnf
ca_name = burpCA
ca_server_name = burpserver
ca_burp_ca = /usr/sbin/burp_ca

Server SSL options:
ssl_dhfile = /etc/burp/dhfile.pem
ssl_cert_ca = /etc/burp/ssl_cert_ca.pem
ssl_cert = /etc/burp/ssl_cert-server.pem
ssl_key = /etc/burp/ssl_cert-server.key
ssl_key_password = password

If you do not want the server to automate the CA stuff, do not set ca_conf.

When the server starts, the ca_conf file will be read, and the CA_DIR value
from that file will be read.
If the CA_DIR directory already exists, the automatic CA setup finishes here.

Next, if ssl_dhfile does not exist, an appropriate dhfile will be generated.
The dhfile is used in encypting the SSL connection with the Diffie-Hellman
protocol.

Next, the CA directory is initialised using ca_burp_ca, which should point to
the burp_ca script.
The name of the CA will be the value of ca_name. 

A key for the burp server is then generated, along with a certificate signing
request to give to the CA. The CA then signs the request. The ssl_cert_ca,
ssl_cert and ssl_key paths are then overwritten with symlinks to the new keys
and certificates.

This concludes the CA setup on the server.

-----

Client CA options:
ca_burp_ca=/usr/sbin/burp_ca
ca_csr_dir=/etc/burp/CA

Client SSL options:
ssl_cert_ca = /etc/burp/ssl_cert_ca.pem
ssl_cert = /etc/burp/ssl_cert-client.pem
ssl_key = /etc/burp/ssl_cert-client.key
ssl_key_password = password
ssl_peer_cn = burpserver

If you do not want the client to automate the CA stuff, do not set ca_burp_ca.

When the client runs (for example, with 'burp -a b'), it will try to connect
to the server using the burp client name (cname) and password. If you haven't
got the client name and password right, everything stops here. 

If the path to ssl_key exists, the client will not try to generate a key and
certificate signing request - it assumes that this has already been done.
Otherwise, a client key is generated at the path of ssl_key, and a certificate
request is generated in the ca_csr_dir directory, named after the client name.

This is copied to CA_DIR on the server, unless the server already has a file
named the same, or a signed certificate with the same name. If either already<commit_msg>Tweak to burp_ca.txt.<commit_after>Certificate Authority (CA) and certificate how-to
-------------------------------------------------

As of burp-1.3.2, the process of generating SSL certificates has been
automated.

Effectively, the automation means that you can set up a new client on the
server (in /etc/burp/clientconfdir/<client>), and the first client to connect
that matches that client name and password will get its certificate signed
and given back. If a different, second client, happens to connect with the
same client name and password, it will be rejected because it doesn't have
a matching certificate.


Server CA options:
ca_conf = /etc/burp/CA.cnf
ca_name = burpCA
ca_server_name = burpserver
ca_burp_ca = /usr/sbin/burp_ca

Server SSL options:
ssl_dhfile = /etc/burp/dhfile.pem
ssl_cert_ca = /etc/burp/ssl_cert_ca.pem
ssl_cert = /etc/burp/ssl_cert-server.pem
ssl_key = /etc/burp/ssl_cert-server.key
ssl_key_password = password

If you do not want the server to automate the CA stuff, do not set ca_conf.

When the server starts, the ca_conf file will be read, and the CA_DIR value
from that file will be read.
If the CA_DIR directory already exists, the automatic CA setup finishes here.

Next, if ssl_dhfile does not exist, an appropriate dhfile will be generated.
The dhfile is used in encypting the SSL connection with the Diffie-Hellman
protocol.

Next, the CA directory is initialised using ca_burp_ca, which should point to
the burp_ca script.
The name of the CA will be the value of ca_name. 

A key for the burp server is then generated, along with a certificate signing
request to give to the CA. The CA then signs the request. The ssl_cert_ca,
ssl_cert and ssl_key paths are then overwritten with symlinks to the new keys
and certificates.

This concludes the CA setup on the server.

-----

Client CA options:
ca_burp_ca=/usr/sbin/burp_ca
ca_csr_dir=/etc/burp/CA

Client SSL options:
ssl_cert_ca = /etc/burp/ssl_cert_ca.pem
ssl_cert = /etc/burp/ssl_cert-client.pem
ssl_key = /etc/burp/ssl_cert-client.key
ssl_key_password = password
ssl_peer_cn = burpserver

If you do not want the client to automate the CA stuff, do not set ca_burp_ca.
Clients as of 1.3.2 will not include the old default certificates, so if you
want to install new clients connecting to a server that is using the old
certificates, you will also have to copy the old certificates onto the client.

When the client runs (for example, with 'burp -a b'), it will try to connect
to the server using the burp client name (cname) and password. If you haven't
got the client name and password right, everything stops here. 

If the path to ssl_key exists, the client will not try to generate a key and
certificate signing request - it assumes that this has already been done.
Otherwise, a client key is generated at the path of ssl_key, and a certificate
request is generated in the ca_csr_dir directory, named after the client name.

This is copied to CA_DIR on the server, unless the server already has a file
named the same, or a signed certificate with the same name. If either already
{'fraction_non_alphanumeric': 0.06628436498566369, 'fraction_numerical': 0.0015179625569235959, 'mean_word_length': 3.9293433083956777, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1018596', 'n_tokens_mistral': 1779, 'n_tokens_neox': 1745, 'n_words': 864}