Use code formatting for example domain names

content/en/docs/profiles.md

@@ -18,7 +18,7 @@ The following validation properties can be controlled by our profiles:
 
 The following certificate properties can be controlled by our profiles:
 
-- **Certificate Common Name:** TLS Certificates can contain names (e.g. domain names or IP addresses) in two places: the [Subject Common Name field](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6) and the [Subject Alternative Names extension](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6). The Common Name used to be the most common place to put a domain name, and is displayed by many certificate-parsing tools. However, the Common Name can only hold one name, while many certificates want to contain multiple names (such as "example.com", "www.example.com", and "blog.example.com"). Today, the Common Name is largely redundant, as whatever name is contained in it is required to _also_ be contained in the Subject Alternative Names extension. Including this field in our certificates is now [NOT RECOMMENDED by the Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#71272-domain-validated).
+- **Certificate Common Name:** TLS Certificates can contain names (e.g. domain names or IP addresses) in two places: the [Subject Common Name field](https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6) and the [Subject Alternative Names extension](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6). The Common Name used to be the most common place to put a domain name, and is displayed by many certificate-parsing tools. However, the Common Name can only hold one name, while many certificates want to contain multiple names (such as `example.com`, `www.example.com`, and `blog.example.com`). Today, the Common Name is largely redundant, as whatever name is contained in it is required to _also_ be contained in the Subject Alternative Names extension. Including this field in our certificates is now [NOT RECOMMENDED by the Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#71272-domain-validated).
 
 - **Key Encipherment Key Usage:** TLS Certificates have a ["Key Usage" extension](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3), which determines what sorts of cryptographic operations the key contained in the certificate is allowed to perform. All Let's Encrypt certificates contain the Digital Signature KU, which is necessary to perform TLS handshakes. The Key Encipherment KU was historically required by old versions of TLS to perform certain kinds of handshakes with RSA keys. However, those operations are now known to be insecure, and have been deprecated and removed from browsers for several years now. Including the Key Encipherment key usage is now [NOT RECOMMENDED by the Baseline Requirements](https://github.com/cabforum/servercert/blob/main/docs/BR.md#712711-subscriber-certificate-key-usage).