Added content and images

src/content/docs/learning-paths/mtls/concepts/benefits.mdx

@@ -0,0 +1,15 @@
+---
+title: Benefits of mTLS
+pcx_content_type: overview
+sidebar:
+  order: 2
+---
+
+- **Stronger Authentication**: mTLS ensures mutual verification between the client and server, confirming that both parties are who they claim to be. This two-way authentication mechanism prevents impersonation and man-in-the-middle attacks, significantly enhancing the overall security.
+
+- **End-to-End Encryption**: All communication between the client and server is encrypted, providing robust protection against eavesdropping and interception. Even if the data is captured by unauthorized parties, it remains secure and unreadable due to encryption.
+
+- **Preserved Data Integrity**: mTLS ensures that data remains unaltered during transit. The protocol verifies the integrity of transmitted information, protecting it from tampering or manipulation by malicious actors, ensuring the data's authenticity.
+
+- **Defense Against Insider Threats**: mTLS strengthens internal network security by adding protection against insider threats. Unlike traditional "castle-and-moat" networking, which trusts anything inside the perimeter, mTLS enforces mutual authentication, ensuring all internal communications are verified and secure.
+

src/content/docs/learning-paths/mtls/concepts/index.mdx

@@ -0,0 +1,13 @@
+---
+title: Introducing mTLS
+pcx_content_type: overview
+sidebar:
+  label: Introducing mTLS
+  order: 1
+---
+
+Mutual TLS ([mTLS](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/)) authentication uses client certificates to ensure traffic between client and server is bidirectionally secure and trusted. mTLS also allows requests that do not authenticate via an identity provider — such as Internet-of-things (IoT) devices — to demonstrate they can reach a given resource.
+
+[TLS (Transport Layer Security)](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/) is a widely-used protocol to ensure secure communication over a network. It ensures confidentiality and integrity by encrypting data and validating the server using digital certificates.
+
+Mutual TLS (mTLS) adds an extra layer by authenticating both parties involved in the communication. The client presents a certificate to the server (in this case Cloudflare) and vice versa.

src/content/docs/learning-paths/mtls/concepts/mtls-cloudflare.mdx

@@ -0,0 +1,22 @@
+---
+title: mTLS at Cloudflare
+pcx_content_type: overview
+sidebar:
+  order: 3
+---
+
+In this implementation guide we will be focusing on the L7 / Application Layer security for HTTP/S requests targeting [proxied](/dns/manage-dns-records/reference/proxied-dns-records/) hostnames, including the [first connection](/ssl/origin-configuration/ssl-modes/) between client and Cloudflare. Use Cloudflare Public Key Infrastructure (PKI) to create Client Certificates.
+
+Some common mTLS use cases are:
+- Protect and verify legitimate API traffic by verifying Client Certificates they provide during TLS/SSL handshakes.
+- Check IoT devices' identity by verifying Client Certificates they provide during TLS/SSL handshakes.
+
+There are two main ways to use mTLS at Cloudflare, either by using [API Shield](https://developers.cloudflare.com/api-shield/) or [Cloudflare Access](/cloudflare-one/policies/access/). Below is a non-exhaustive overview table of their differences:
+
+| Feature | API Shield (Client Certificate \+ WAF) | Cloudflare Access (mTLS) |
+| :---- | :---- | :---- |
+| Mainly used for | External Authentication (i.e. APIs) | Internal Authentication (i.e. employees) |
+| Availability | By default, 100 Client Certificates per Zone are included. For more certificates or [API Shield features](/api-shield/), contact your account team. | Zero Trust Enterprise only feature. |
+| [Certificate Authority (CA)](/ssl/concepts/#certificate-authority-ca)  | Cloudflare-managed or customer-uploaded (BYO CA). There’s a soft-limit of up to [five customer-uploaded CAs](/ssl/client-certificates/byo-ca/#availability). | Customer-uploaded only (BYO CA). There’s a soft-limit of up to [50 CAs](/cloudflare-one/account-limits/#access). |
+| Client Certificate Details | Forwarded to the origin server via [Cloudflare API](/ssl/client-certificates/enable-mtls/#cloudflare-api), [Cloudflare Workers](/ssl/client-certificates/enable-mtls/#cloudflare-workers), and [Managed Transforms](/ssl/client-certificates/enable-mtls/#managed-transforms). | Forwarded to the origin server via [Cloudflare API](/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication/#cloudflare-api), [Cloudflare Workers](/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication/#cloudflare-workers), and [Managed Transforms](/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication/#managed-transforms). Client Certificate headers and [Cf-Access-Jwt-Assertion](/cloudflare-one/identity/authorization-cookie/validating-json/) JWT header can be forwarded to the origin server. |
+| Client Certificates Revocation | Use the WAF [Custom Rules](/waf/custom-rules/) to check for [*cf.tls\_client\_auth.cert\_revoked*](/ssl/client-certificates/revoke-client-certificate/), which only applies to Cloudflare-managed CA. <br /><br /> For BYO CAs, it would be the same approach as with Cloudflare Access. | Generate a [Certificate Revocation List (CRL)](/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication/#create-a-crl) and enforce the revocation in a Cloudflare Worker. |

src/content/docs/learning-paths/mtls/index.mdx

@@ -0,0 +1,15 @@
+---
+title: mTLS at Cloudflare
+type: developers-site
+new_learning_path: true
+pcx_content_type: learning-path
+head:
+  - tag: title
+    content: mTLS at Cloudflare
+description: Safeguarding APIs and devices on Cloudflare's network.
+
+---
+
+import { LearningPath } from "~/components"
+
+<LearningPath file="mtls" />

src/content/docs/learning-paths/mtls/mtls-api-shield/index.mdx

@@ -0,0 +1,77 @@
+---
+title: mTLS with API Shield
+pcx_content_type: overview
+sidebar:
+  order: 1
+---
+
+:::note
+This implementation requires an active [Zone](/fundamentals/setup/accounts-and-zones/#zones), a valid [Edge Certificate](/ssl/edge-certificates/), and [proxied](https://developers.cloudflare.com/dns/manage-dns-records/reference/proxied-dns-records/) hostname. <br />
+
+API Shield is not required to use mTLS. <br />
+
+By default, mTLS uses Client Certificates issued by a Cloudflare Managed CA. Cloudflare generates a unique CA for each customer account, meaning that Client Certificates all validate against an account-level Cloudflare CA.
+:::
+
+## 1. Enable mTLS
+
+1. Go to your Cloudflare dashboard and selecting your account.
+2. Select **SSL/TLS** > **[Client Certificates](/ssl/client-certificates/)** tab and add the Hosts (hostnames) you want to [enable mTLS](/ssl/client-certificates/enable-mtls/) for. 
+
+    Example host: [mtls-test.example.com](https://mtls-test.example.com/)
+
+3. Select **Create Certificate** to generate the private key (usually referred to as Private Certificate) and Certificate Signing Request (CSR) with Cloudflare (which includes the Public Certificate), or use your own private key and CSR. Using your own allows you to also [label client certificates](/ssl/client-certificates/label-client-certificate/).
+
+## 2. Install the client certificate
+
+In order for a client to utilize the Client Certificate you created, it must be on the devices that you want to use them on. You will want to place them in the same directory as your process / script that targets your APIs / hostnames.
+
+We generally recommended using one Client Certificate per device. Configuring your system to actually use the Public and Private Certificates is especially important.
+
+An example is to [add both certificates to the Keychain](https://support.apple.com/en-gb/guide/keychain-access/kyca2431/mac) on a MacBook laptop. 
+
+Another example is to generate a [PKCS12 (P12) certificate](https://en.wikipedia.org/wiki/PKCS_12) file and then [add it to your browser](https://www.ibm.com/docs/en/engineering-lifecycle-management-suite/lifecycle-management/7.0.2?topic=dashboards-importing-certificates-configuring-browsers):
+
+```txt
+openssl pkcs12 -export -out certificate.p12 -inkey private-cert.pem -in cert.pem
+```
+
+Example using cURL command:
+
+```cURL
+curl -v --cert cert.pem --key private-cert.pem <HOSTNAME>
+```
+
+## 3. Validate the client certificate in the WAF
+
+mTLS is verified and checked in the [Cloudflare WAF phase](/waf/reference/phases/). This is done by creating WAF [Custom Rules](/waf/custom-rules/) using the dynamic fields.
+
+All Client Certificate details can be found in the [`cf.tls_*`](/ruleset-engine/rules-language/fields/dynamic-fields/#cftls_cipher) dynamic fields in the [Cloudflare Ruleset Engine](/ruleset-engine/).
+
+Example WAF Custom Rule with action block:
+
+![Example of a WAF custom rule with an action block in the Cloudflare dashboard during the validate client certificate step](~/assets/images/learning-paths/mtls/waf-custom-rule-action-block.png)
+
+## Demo
+
+:::note
+Ensure you're not using a VPN that could interfere with certificates or TLS decryption. If needed, enable [Split Tunnels](/cloudflare-one/connections/connect-devices/warp/configure-warp/route-traffic/split-tunnels/) for specific hostnames to bypass the VPN for trusted services, such as the mTLS hostnames.
+:::
+
+With the Public and Private Certificates in the same directory, with this cURL command, we will gain access:
+
+```curl
+curl -I --cert cert.pem --key private-cert.pem https://mtls-test.example.com/mtls-test
+
+HTTP/2 200 
+server: cloudflare
+```
+
+Without the certificates, we would see the following:
+
+```curl
+$ curl -I https://mtls-test.example.com/mtls-test
+
+HTTP/2 403
+server: cloudflare
+```

src/content/docs/learning-paths/mtls/mtls-api-shield/related-features.mdx

@@ -0,0 +1,147 @@
+---
+title: mTLS related features
+pcx_content_type: overview
+sidebar:
+  order: 2
+---
+
+## Label Client Certificates
+
+To make it easier to differentiate between Client Certificates, you can generate your own private key and CSR, and enter information that will be incorporated into your certificate request, essentially [labeling your Client Certificates](/ssl/client-certificates/label-client-certificate/).
+
+## Certificate Revocation
+
+In cases of noticing excessive traffic, anomalous traffic (strange sequences of requests), or generally too many attack attempts registered from specific devices using your Client Certificates, it is best to [revoke](/ssl/client-certificates/revoke-client-certificate/) those.
+
+Additionally, ensure to have a WAF [Custom Rule](/waf/custom-rules/) in place to block [revoked](/api-shield/security/mtls/configure/#check-for-revoked-certificates) Client Certificates. Review the available [`cf.tls_*`](/ruleset-engine/rules-language/fields/dynamic-fields/#cftls_cipher) dynamic fields.
+
+Example WAF Custom Rule with action block:
+
+![Example expression for certification revocation using a WAF custom rule in the Cloudflare dashboard](~/assets/images/learning-paths/mtls/certification-revocation-custom-rule.png)
+
+```text
+(cf.tls_client_auth.cert_revoked)
+```
+
+A better approach may be to check for unverified or revoked client certificates:
+
+```txt
+(not cf.tls_client_auth.cert_verified) or cf.tls_client_auth.cert_revoked
+```
+
+Generally, ensure client certificates are rotated regularly and safely to reduce the risk of compromise.
+
+## Forward a client certificate
+
+There are multiple ways to [forward a client certificate](/ssl/client-certificates/enable-mtls/#forward-a-client-certificate) to your origin server.
+
+## Bring your own CA for mTLS
+
+If you already have mTLS implemented, client certificates are already installed on devices, and therefore you'd like to use your own Certificate Authority (CA), this is possible by b[ringing your own CA for mTLS](/ssl/client-certificates/byo-ca/).
+
+Here you can use the [Replace Hostname Associations API endpoint](/api/operations/client-certificate-for-a-zone-put-hostname-associations) to enable mTLS in each hostname that should use the CA for mTLS validation, essentially associating your CAs specific with hostnames.
+
+:::note
+Each Enterprise account can upload up to five CAs, though this can be increased. Contact your account team if you require more.
+:::
+
+## Client Certificate Deployment
+
+There are different ways to safely and securely deploy Client Certificates across devices. 
+
+Some of the most used methods are [embedding](https://developers.cloudflare.com/ssl/client-certificates/configure-your-mobile-app-or-iot-device/#step-3--embed-the-client-certificate-in-your-mobile-app) the Client Certificate into an application and allowing user devices to download and install that app, or use mobile device management (MDM) to distribute certificates across devices, or to allow user devices to directly download and install the Client Certificate into a device's Certificate Store.
+
+Issuing a certificate is an important step, so if possible, perform thorough client verification.
+
+You can also leverage Service Mesh, where in complex microservices environments, use those to automate and enforce mTLS at scale. For example, Cloudflare services can handle external traffic security, while Service Mesh technologies enforce mTLS for east-west traffic within your network. This ensures that external traffic is secured by Cloudflare, while internal microservice communication is protected using mTLS via the Service Mesh.
+
+## Customize Cipher Suites
+
+It is generally recommended to [customize the cipher suites](/ssl/edge-certificates/additional-options/cipher-suites/customize-cipher-suites/) of your Cloudflare [Edge Certificates](/ssl/edge-certificates/). This only applies to the Edge Certificates, not Client Certificates.
+
+The recommended TLS versions for mTLS are:
+- TLS 1.2: still broadly compatible and secure.
+- TLS 1.3: preferred for new implementations due to its enhanced security and efficiency.
+
+Using outdated versions like TLS 1.0 or 1.1 is not recommended due to known vulnerabilities.
+
+:::note
+For modern mTLS implementations, Elliptic Curve Cryptography (EC) is recommended because it offers faster handshakes and better performance, uses smaller key sizes result in reduced computational overhead while maintaining strong security, and EC is more scalable for large-scale deployments, such as in cloud-native applications, microservices, and mobile networks. RSA is only recommended if you have legacy systems that cannot support EC or if you require compatibility with systems that only work with RSA.
+:::
+
+## TLS Session Resumption
+
+Browsers connecting to a domain with a [wildcard](/dns/manage-dns-records/reference/wildcard-dns-records/) [Edge Certificate](ssl/edge-certificates/) in place, connecting to the same domain's mTLS subdomain could cause a non-authentication event, due to TLS Session Resumption.
+
+It is generally not recommended to use wildcard certificates.
+
+Review the [troubleshooting documentation](/ssl/client-certificates/troubleshooting/) for more info.
+
+## TLS Session Renegotiation
+
+:::note
+Resumption and renegotiation are essentially opposites. Resumption re-establishes a previous TLS session over a new TCP connection, keeping the same TLS parameters. In contrast, renegotiation updates certain TLS parameters within an existing session, continuing over the same TCP connection.
+:::
+
+If you need to use Client Certificates after the TLS handshake via renegotiation, you'll need to use a prior version. This is because TLS 1.3 doesn't support renegotiation.
+
+For example, if you're using mTLS and you're restricting requests to certain folders, based on a URL path in the request, rather than all content on your origin server, a TLS renegotiation may be triggered. Connections using TLS 1.3 don't support renegotiation.
+
+## Chain of Trust
+
+Customers creating Client Certificates and selecting the the option to "_use my private key and CSR_", providing a CSR, which was provided by your end-customers, in order to generate the Client Certificates and share it with your end-customers. However, if your end-customers request the Certificate Chain, this can potentially be shared by the Cloudflare account team. 
+
+Contact your account team for more information.
+
+## WAF for Client Certificates
+
+:::note
+[Revoked](/api-shield/security/mtls/configure/#check-for-revoked-certificates) Client Certificates are not automatically blocked unless you have an active WAF Custom Rule specifically checking for and blocking them. This check only applies to Client Certificates issued by the Cloudflare-managed CA. Cloudflare currently does not check certificate revocation lists (CRL) for CAs that have been uploaded by the customer ([BYO CA](/ssl/client-certificates/byo-ca/)). One can opt for Workers to manage a custom business logic and block revoked Client Certificates. See the [Workers section](placeholder) for more information.
+:::
+
+In order to effectively implement mTLS with Cloudflare, it is strongly recommended to properly configure the [Cloudflare WAF](/waf/). Review the available []`cf.tls_*`](/ruleset-engine/rules-language/fields/dynamic-fields/#cftls_cipher) dynamic fields.
+
+Example WAF Custom Rule with action block:
+
+![Example expression for configure a WAF Custom Rule with action block ](~/assets/images/learning-paths/mtls/configure-waf-custom-rule.png)
+
+```txt
+(http.host in {"mtls.example.com" "mtls2.example.com"} and (not cf.tls_client_auth.cert_verified or cf.tls_client_auth.cert_revoked))
+```
+
+This expression will check if the request is coming from one of the hostnames and will block the request if the Client Certificate is either not verified or revoked.
+
+Another example WAF Custom Rule with action block, using the [cf.tls_client_auth.cert_fingerprint_sha256](/ruleset-engine/rules-language/fields/dynamic-fields/#cftls_client_authcert_fingerprint_sha256) field, for a specific Client Certificate (replace `ADD_STRING_OF_CLIENT_CERT_SHA256_FINGERPRINT`):
+
+![Example expression of a WAF Custom Rule with action block using the cf.tls_client_auth.cert_fingerprint_sha256 field](~/assets/images/learning-paths/mtls/waf-client-certificates-fingerprint.png)
+
+```txt
+(http.request.uri.path in {"/headers"} and http.host in {"mtls.example.com" "mtls2.example.com"} and not cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_fingerprint_sha256 ne "ADD_STRING_OF_CLIENT_CERT_SHA256_FINGERPRINT")
+```
+
+## Rate Limiting by Client Certificates
+
+By enabling [forwarding a certificate](/ssl/client-certificates/enable-mtls/#cloudflare-api) via the Cloudflare API, the first request of an mTLS connection will include the following headers:
+- `Cf-Client-Cert-Der-Base64` (raw certificate in DER format, encoded as base64)
+- `Cf-Client-Cert-Sha256` (SHA256 fingerprint of the certificate)
+
+The header `Cf-Client-Cert-Sha256` can be used within the [Rate Limiting characteristics](/waf/rate-limiting-rules/parameters/#with-the-same-characteristics) “Header value of”.
+
+Example [Rate Limiting Rule](/waf/rate-limiting-rules/):
+
+![Example exmpression of a rate limiting rule from the Cloudflare dashboard](~/assets/images/learning-paths/mtls/rate-limiting-rule.png)
+
+```txt
+(http.host in {"mtls.example.com" "mtls2.example.com"} and cf.tls_client_auth.cert_verified)
+
+With the same characteristics...
+"Header value of": "Cf-Client-Cert-Sha256"
+```
+
+## Cloudflare API Shield
+
+In addition to mTLS, customers can purchase [API Shield](/api-shield/) features, such as API Discovery, API Routing, Volumetric Abuse Detection, Sequence Mitigation, JWT Validation, and Schema Validation.
+
+## Cloudflare Workers
+
+Cloudflare Workers can provide details around the Client Certificate, such as returning information via headers to the client or to the origin server. Learn more in the [mTLS with Workers section](placeholder) below.