> For the complete documentation index, see [llms.txt](https://clients.medianova.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://clients.medianova.com/products/security/ssl-tls-encryption.md). # SSL/TLS Encryption Configure SSL/TLS certificates to secure HTTPS connections between clients and Medianova CDN edge servers. **Transport Layer Security (TLS)** encrypts data transmitted over HTTPS, protects its integrity, and authenticates servers using digital certificates. Although the term SSL remains common, modern HTTPS connections use TLS. Medianova supports certificate management through the [Medianova Control Panel](https://cloud.medianova.com), including uploading existing certificates and requesting free certificates for supported domains. ## How SSL/TLS Works on Medianova CDN
TLS connections between clients, Medianova CDN edge servers, and origin servers

Client-to-edge and edge-to-origin encryption

When a client requests content over HTTPS: 1. The client establishes a connection to a Medianova CDN edge server. 2. The edge server presents an SSL/TLS certificate for the requested hostname. 3. The client validates the certificate, and the TLS handshake establishes an encrypted connection. 4. The CDN serves the requested content from cache or retrieves it from the origin server. 5. If HTTPS is configured for the origin connection, the CDN establishes a separate TLS connection to the origin server. {% hint style="info" %} Client-to-edge and edge-to-origin encryption are configured separately. Enabling HTTPS for a CDN Resource does not automatically guarantee that connections to its origin use HTTPS. {% endhint %} ## Certificate Options Medianova provides several certificate options for securing CDN Resources. | Option | Description | Use Case | | ---------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | **Existing Certificate** | Select an SSL/TLS certificate already available in your Medianova account. | Reusing a certificate across eligible CDN Resources. | | **Custom Certificate** | Upload your own certificate and corresponding private key. | Using a certificate issued by your preferred Certificate Authority (CA). | | **Free SSL – Single Domain** | Request a certificate for a specific hostname. | Securing an individual custom domain. | | **Free SSL – Wildcard** | Request a certificate covering subdomains at one level beneath a specified domain. | Securing multiple first-level subdomains. | ### Single-Domain Certificates A single-domain certificate secures the hostname included in the certificate. For example, a certificate issued for: ``` cdn.example.com ``` Covers that hostname but does not automatically cover: ``` assets.example.com ``` Use a single-domain certificate when the CDN Resource is accessed through one specific hostname. ### Wildcard Certificates A wildcard certificate secures multiple first-level subdomains under a specified domain. For example: ``` *.example.com ``` Covers hostnames such as: ``` cdn.example.com assets.example.com media.example.com ``` However, it does not automatically cover: ``` example.com images.cdn.example.com ``` The apex domain and deeper subdomain levels require separate certificate coverage unless explicitly included in the certificate. {% hint style="info" %} A certificate must cover every hostname used to access the CDN Resource over HTTPS. Wildcard coverage is limited to the domain level represented by the wildcard. {% endhint %} ## Certificate Validation Types SSL/TLS certificates can also differ in their validation requirements.
Validation TypeDescription
Domain Validation (DV)Verifies control of the domain or hostname.
Organization Validation (OV)Verifies domain control and additional organization identity information.
Extended Validation (EV)Requires more extensive verification of the requesting organization's identity.
These validation types describe the identity verification performed by the issuing CA. They do not indicate different TLS encryption strengths. Certificates may also contain multiple hostnames in their **Subject Alternative Name (SAN)** extension. {% hint style="info" %} Certificate validation types and hostname coverage are separate characteristics. A certificate may include multiple SAN entries or wildcard names regardless of its validation category, subject to the issuing CA's policies. The availability of DV, OV, EV, and SAN certificate configurations depends on the selected certificate provider and issuance method. {% endhint %} ## Certificate Configuration SSL/TLS certificates can be configured when creating a CDN Resource or managed through the SSL/TLS section of the [Medianova Control Panel](https://cloud.medianova.com). ### Use an Existing Certificate Select a previously configured certificate that covers the hostname associated with the CDN Resource. ### Upload a Custom Certificate Provide a certificate issued by a trusted CA and its corresponding private key. Medianova supports certificate configuration using supported upload methods, including certificate and private key files, pasted certificate data, and PFX-based certificate import. See Upload and Manage SSL Certificates for configuration details. ### Request a Free SSL Certificate Request a free certificate for a supported single domain or wildcard domain. Certificate issuance may require domain ownership validation. The certificate must be successfully validated and provisioned before it can secure HTTPS connections. {% hint style="info" %} See [Use Free SSL Certificates](/products/security/ssl-tls-encryption/use-free-ssl-certificates.md) for validation and provisioning instructions. {% endhint %} ## TLS Protocol Versions TLS protocol versions determine the cryptographic mechanisms available when establishing secure connections. **TLS 1.2** and **TLS 1.3** are recommended for modern HTTPS deployments. TLS 1.3 simplifies the handshake and removes several legacy cryptographic mechanisms, while TLS 1.2 remains relevant for compatibility with supported clients. The negotiated TLS version depends on the protocols supported by both the client and the CDN endpoint. ## Important Notes * **Certificate coverage:** The certificate must include the hostname used by clients to access the CDN Resource. * **Certificate status:** Newly requested certificates may remain pending until domain validation and provisioning are complete. * **Certificate renewal:** Uploaded certificates must remain valid and be replaced or renewed before expiration. * **Origin encryption:** Configure HTTPS separately for origin connections when end-to-end transport encryption is required. * **Mixed content:** HTTPS pages should load dependent resources over HTTPS to avoid browser mixed-content restrictions. * **Custom domains:** Ensure the custom domain and its DNS configuration are correctly associated with the intended CDN Resource. ## Related Concepts * [Upload and Manage SSL Certificates](/products/security/ssl-tls-encryption/upload-and-manage-ssl-certificates.md) * [Use Free SSL Certificates](/products/security/ssl-tls-encryption/use-free-ssl-certificates.md) * [CNAME & SSL](/products/performance-cdn/static-content-delivery/advanced-configuration/cname-and-ssl.md) * [Extract Certificate and Private Key from a PKCS#12 (.pfx) File](/products/security/ssl-tls-encryption/extract-crt-and-key-files-from-a-pfx-certificate.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://clients.medianova.com/products/security/ssl-tls-encryption.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.