book: clean up whitespace

docs/book/src/quinn/certificate.md

@@ -1,22 +1,22 @@
 # Certificates
 
-In this chapter, we discuss the configuration of the certificates that are **required** for a working Quinn connection. 
+In this chapter, we discuss the configuration of the certificates that are **required** for a working Quinn connection.
 
-As QUIC uses TLS 1.3 for authentication of connections, the server needs to provide the client with a certificate confirming its identity, and the client must be configured to trust the certificates it receives from the server. 
+As QUIC uses TLS 1.3 for authentication of connections, the server needs to provide the client with a certificate confirming its identity, and the client must be configured to trust the certificates it receives from the server.
 
 ## Insecure Connection
 
-For our example use case, the easiest way to allow the client to trust our server is to disable certificate verification (don't do this in production!). 
+For our example use case, the easiest way to allow the client to trust our server is to disable certificate verification (don't do this in production!).
 When the [rustls][3] `dangerous_configuration` feature flag is enabled, a client can be configured to trust any server.
 
 Start by adding a [rustls][3] dependency with the `dangerous_configuration` feature flag to your `Cargo.toml` file.
 
 ```toml
 quinn = "*"
 rustls = { version = "*", features = ["dangerous_configuration", "quic"] }
-``` 
+```
 
-Then, allow the client to skip the certificate validation by implementing [ServerCertVerifier][ServerCertVerifier] and letting it assert verification for any server. 
+Then, allow the client to skip the certificate validation by implementing [ServerCertVerifier][ServerCertVerifier] and letting it assert verification for any server.
 
 ```rust
 // Implementation of `ServerCertVerifier` that verifies everything as trustworthy.
@@ -43,7 +43,7 @@ impl rustls::client::ServerCertVerifier for SkipServerVerification {
 }
 ```
 
-After that, modify the [ClientConfig][ClientConfig] to use this [ServerCertVerifier][ServerCertVerifier] implementation. 
+After that, modify the [ClientConfig][ClientConfig] to use this [ServerCertVerifier][ServerCertVerifier] implementation.
 
 ```rust
 fn configure_client() -> ClientConfig {
@@ -55,17 +55,17 @@ fn configure_client() -> ClientConfig {
     ClientConfig::new(Arc::new(crypto))
 }
 ```
- 
+
 Finally, if you plug this [ClientConfig][ClientConfig] into the [Endpoint::set_default_client_config()][set_default_client_config] your client endpoint should verify all connections as trustworthy.
 
 ## Using Certificates
 
-In this section, we look at certifying an endpoint with a certificate. 
+In this section, we look at certifying an endpoint with a certificate.
 The certificate can be signed with its key, or with a certificate authority's key.
 
 ### Self Signed Certificates
 
-Relying on [self-signed][5] certificates means that clients allow servers to sign their certificates. 
+Relying on [self-signed][5] certificates means that clients allow servers to sign their certificates.
 This is simpler because no third party is involved in signing the server's certificate.
 However, self-signed certificates do not protect users from person-in-the-middle attacks, because an interceptor can trivially replace the certificate with one that it has signed. Self-signed certificates, among other options, can be created using the [rcgen][4] crate or the openssl binary.
 This example uses [rcgen][4] to generate a certificate.
@@ -93,13 +93,13 @@ For this example, we use [Let's Encrypt][6], a well-known Certificate Authority
 Because we're generating a certificate for an internal test server, the process used will be slightly different compared to what you would do when generating certificates for an existing (public) website.
 
 On the certbot website, select that you do not have a public web server and follow the given installation instructions.
-certbot must answer a cryptographic challenge of the Let's Encrypt API to prove that you control the domain. 
+certbot must answer a cryptographic challenge of the Let's Encrypt API to prove that you control the domain.
 It needs to listen on port 80 (HTTP) or 443 (HTTPS) to achieve this. Open the appropriate port in your firewall and router.
 
 If certbot is installed, run `certbot certonly --standalone`, this command will start a web server in the background and start the challenge.
-certbot asks for the required data and writes the certificate to `cert.pem` and the private key to `privkey.pem`.  
-These files can then be referenced in code.  
- 
+certbot asks for the required data and writes the certificate to `cert.pem` and the private key to `privkey.pem`.
+These files can then be referenced in code.
+
 ```rust
 use std::{error::Error, fs::File, io::BufReader};
 
@@ -135,19 +135,19 @@ After configuring plug the configuration into the `Endpoint`.
 let server_config = ServerConfig::with_single_cert(certs, key)?;
 ```
 
-This is the only thing you need to do for your server to be secured. 
+This is the only thing you need to do for your server to be secured.
 
 **Configure Client**
 
 ```rust
 let client_config = ClientConfig::with_native_roots();
 ```
 
-This is the only thing you need to do for your client to trust a server certificate signed by a conventional certificate authority. 
+This is the only thing you need to do for your client to trust a server certificate signed by a conventional certificate authority.
 
 <br><hr>
 
-[Next](set-up-connection.md), let's have a look at how to set up a connection. 
+[Next](set-up-connection.md), let's have a look at how to set up a connection.
 
 [1]: https://en.wikipedia.org/wiki/Certificate_authority
 [2]: https://en.wikipedia.org/wiki/Public_key_certificate