[Blog](/blog) Show links Resources [Blog](/blog) [Breaches](/breaches) [eBooks, reports, & more](/resources) [Events](/events) [News](/news) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) Show links Categories [Attack Surface Management](/category/attack-surface-management) [Company News](/category/company-news) [Compliance and Regulations](/category/compliance-and-regulations) [Cybersecurity](/category/cybersecurity) [Data Breaches](/category/data-breaches) [DevOps](/category/devops) [Human Cyber Risk](/category/human-cyber-risk) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) [Third-Party Risk Management](/category/third-party-risk-management) [Vendor Risk Management](/category/vendor-risk-management) [How to Identify and Strengthen Weak SSL](/blog/weak-ssl) Publish date October 18, 2026 {x} minute read # How to Identify and Strengthen Weak SSL [Get a demo](/contact-sales) [Free trial](/demo) [Download the PDF guide](/resources/complete-guide-to-data-breaches) [Free trial](/demo) Written by [Caitlin Postal](/team/caitlin-postal) Technical Writer Reviewed by [Greg Pollock](/team/greg-pollock) Director of Research and Insights Greg is a CISA-certified cybersecurity researcher who holds multiple patents for data leak detection. His findings have been featured in The New York Times, Forbes, and Wired. Table of contents eBook A Complete Guide to Data Breaches Free resource ### A Complete Guide to Data Breaches Learn how to avoid a costly data breach with a comprehensive prevention strategy. [Download now](/resources/complete-guide-to-data-breaches) Your website or application must be set up within communications networks in order to be accessible to users. Each connection point to an external environment is a possible attack vector that makes up your attack surface. In order to encrypt traffic between your site and your users, you can set your system up with an SSL certificate that uses SSL/TLS protocols to secure traffic. However, if your server uses a weak SSL algorithm or an insecure SSL/TLS version, you'll need to update the system to protect your customers and your assets. This article provides a brief introduction to SSL/TLS networking, how to identify weak and insecure elements in your SSL setup, and what actions you can take to secure your system and protect user data. ## How Network Communications and SSL/TLS Handshakes Function The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols provide encrypted communications between public web systems through a defined public key infrastructure (PKI). Most websites and apps use [SSL certificates](https://www.upguard.com/blog/ssl-certificate) to supply a cryptographic key that will authenticate between servers and establish a secure transmission method, typically over an [HTTPS (Hypertext Transfer Protocol Secure)](https://www.upguard.com/blog/what-is-https) connection. SSL/TLS certificates are a type of X.509 certificate used for identity authentication between your servers and users' browsers. SSL/TLS security provides the strong cryptography required by regulations such as [PCI-DSS](https://www.upguard.com/blog/pci-compliance) and [FISMA](https://www.upguard.com/blog/fisma) through use of public/private key encryption. SSL/TLS protocols establish communication channels through encryption, authentication, and integrity. SSL/TLS communication uses cipher suites that ensure multiple levels of cryptography. A cipher suite is a set of cryptographic algorithms used during the TLS handshake to help secure communications, and each cipher suite is named with the algorithms that make up the suite. A [TLS handshake](https://www.upguard.com/blog/http-vs-https#toc-2) is how networks communicate with each other over secure means: 1. The server (your website or application) listens on port 443 for secure HTTPS connection requests. 2. The client (a user's browser) connects to port 443 and exchanges messages with the server to determine the validity of the exchange and which cryptographic parameters to use for this session. (These are often referred to as the client hello, server hello, and client key exchange.) 3. Once the TLS version and cipher suite are agreed upon and the digital certificates have been exchanged and authenticated, an encrypted session is opened and secure communications can be relayed between the client and the server until the client ends the session. Every certificate uses an encryption algorithm to make the encrypted data unreadable without the appropriate key pair that can decrypt the data. The encryption algorithms that make up a cipher suite are designed to be difficult to reverse engineer, and certificates are constantly adapting to more secure standards, which is why it is so important to [renew certificates before they expire](https://www.upguard.com/blog/what-is-ssl-certificate-expiration#toc-3). However, if an SSL certificate relies on an outdated version or insecure cipher suites, then the SSL connection may not be as secure as your users expect. Because the cipher suite is selected through a negotiation between the client (a user's browser) and the server (your site), weak SSL cipher suites should be disabled so that they are not eligible for selection. If you are using [OpenSSL](https://www.openssl.org/) as your SSL/TLS toolkit, you can run \[.rt-script]openssl ciphers\[.rt-script] to generate the cipher list that you currently have available. Cipher suites that are known to be weak, like the SSLv2 and SSLv3 protocols, should be updated so that your users' sessions are protected. Insecure TLS versions and weak cipher suites may introduce [Common Vulnerabilities and Exposures](https://www.upguard.com/blog/cve) (CVEs), decryption exploitation, padding-oracle (POODLE) attacks, and [man-in-the-middle attacks](https://www.upguard.com/blog/man-in-the-middle-attack). Any known CVEs include CVSS scores that indicate the risk impact they could have. Additionally, users may not be able to make a secure connection if there are insecure versions or weak cipher suites, and any weak connections could potentially be decrypted by a well-resourced attacker. Because outdated versions may remain enabled for legacy support, it's important to disable known insecure versions and migrate to the most recent encryption algorithms. In order to make those changes, you will need to identify any weak SSL/TLS versions, insecure cipher suites, or otherwise concerning aspects of your certificate setup. ## How to Identify Weak SSL Ciphers and Insecure TLS The Open Worldwide Application Security Project (OWASP) provides a variety of resources for examining your SSL/TLS security from inside your own systems. You can check your ports and other SSL services with [OWASP's guidance](https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_SSL_TLS_Ciphers_Insufficient_Transport_Layer_Protection), but it can be time-consuming to run manual investigations. You can also use an automated scanning tool that accounts for the necessary data to ensure that you can quickly identify any weak links in the encryption standards for your external assets. [UpGuard Breach Risk](https://www.upguard.com/product/breach-risk) provides continuous monitoring and automated scanning for potential threats, including known vulnerabilities related to SSL/TLS protocol. In addition to risks related to [SSL certificate expiration](https://www.upguard.com/blog/what-is-ssl-certificate-expiration) and missing SSL certificates, UpGuard scans for weak or otherwise insecure SSL/TLS configurations. UpGuard evaluates collected data and compare the expected response against the actual response for a specified asset, such as a domain or IP address. Our process notes the detection date at which this result was first identified so that you can stay up-to-date with security across your systems. For any given asset, UpGuard will provide a list of additional checks we have run, which enables you to identify related findings together and create a plan of action. You can always export a PDF version of findings for a given asset to be shared with relevant stakeholders. The PDF findings will list current risks by highest severity first, followed by additional checks that are not currently at risk. UpGuard users are notified with these risk findings for weak and insecure SSL: * **Weak SSL algorithm** * **Insecure SSL/TLS versions available** * **Insecure cipher suite supported** and **Weak cipher suites supported** * **Untrusted SSL certificate** The **Weak SSL algorithm** finding evaluates whether the industry standard SHA-256 encryption algorithm is in use with your SSL certificate. SHA-256 computes multiple rounds of 32-bit hash functions, which is in accordance with the [Federal Information Processing Standards (FIPS) 180-4](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf) for secure hash standards. UpGuard will scan for the expected SHA-256 encryption algorithm and, if it is not in use, identify which SHA algorithm is in use. The **Insecure SSL/TLS versions available** finding identifies which version of SSL/TLS is in use across your systems. UpGuard scans for any known insecure protocol versions, including SSL versions 1, 2, and 3, as well as TLS version 1, which are known to be susceptible to padding-oracle attacks ("POODLE"). The **Insecure SSL/TLS versions available** finding communicates whether your system has a known insecure version that should be disabled against the expected response (no known insecure versions). Frequently, an insecure protocol version is connected to the **Weak cipher suites supported** finding. Each cipher suite is named according to its algorithmic makeup, so you can quickly identify the components that make up any given cipher suite. With the \[.rt-script]TLSv1.0: TLS\_ECDHE\_RSA\_WITH\_RC4\_128\_SHA\[.rt-script] cipher suite as an example, you can analyze each component: * **TLSv1.0**: This sample cipher suite is supported by TLS version 1.0, which was deprecated in 2021 due to security concerns. * **ECDHE\_**: The sample uses the Elliptic-curve Diffie-Hellman Ephemeral (ECDHE) key exchange, which allows for distinct key exchange during the TLS handshake. While ECDHE is an accepted secure algorithm, the remaining algorithms in the sample are not secure. * **RSA\_WITH\_RC4\_128\_**: The sample cipher suite also incorporates RSA authentication with Rivest Cipher 4 with 128-bit key (RC4 128). RC4 has a flaw that makes it incredibly susceptible to decryption, particularly with the 128-bit key. * **SHA**: This sample also uses the Secure Hash Algorithm 1 (SHA-1) by default, despite [deprecation of SHA-1](https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm) to move to improved SHA options with larger key sizes for data encryption. You can add any weak cipher suite, including the sample provided, to a blocklist so that it cannot be used, though it is also beneficial to know how to identify elements of weak cryptographic algorithms. Most SSL certificates are issued from trusted certificate authorities known to most browsers. However, certificates can also be self-signed or issued by an untrusted authority. A self-signed certificate and certificates from an untrusted authority mean that your user cannot trust that the certificate provides the same level of encrypted security as a certificate from a trusted certificate authority. Additionally, some browsers will not allow traffic to these types of certificates as they cannot verify the certificate authority. If you receive the **Untrusted SSL Certificate** finding, you should replace the untrusted certificate with a valid certificate that you generate through a certificate signing request. If your domain or IP address has other risk findings related to SSL/TLS, you may be able to mitigate those with a new certificate as well. ## How to Mitigate Insecure SSL and Weak Cipher Suite Findings Once you have identified security concerns related to the strength of your SSL/TLS certificates, you can make changes to protect your system and strengthen your web server's security posture. After resolving any common issues, you can prevent attacks on weak cipher suites by implementing up-to-date standards and disabling any known weak cipher suites or insecure versions of SSL/TLS. ### Update SSL/TLS versions Replace certificates that use insecure SSL/TLS versions or weak cipher suites. All versions of SSL and TLS versions below 1.2 are insecure, so only TLS 1.2 or higher should be allowed for your system. ### Upgrade the cipher suites When you request a new certificate, you can specify stronger encryption algorithms from the issuer. Encryption standards are constantly changing, so it is important to renew certificates on a recurring basis (at least once per year, if not more frequently) so that your TLS cipher suites are aligned to the current TLS standards. Modern ciphers, such as the DHE and ECDHE families and Galois-counter mode (GCM), are still in use. ECDHE is stronger than DHE, so you can remove DHE values but that may result in reduced compatibility across operating systems and devices. Likewise, the Advanced Encryption Standard (AES) provides strong symmetric-key encryption and has three available key sizes: AES-128 for 128-bit keys, AES-192 for 192-bit keys, and AES-256 for 256-bit keys. ### Disallow any weak algorithms You can also specify SSL ciphers you wish to exclude from your system to ensure up-to-date compatibility with modern browsers. There are some encryption algorithms that are known to be insecure and which should be disabled for use with your web application, including the Data Encryption Standard (DES), Electronic Codebook (ECB), and Cipher Block Chaining (CBC). Other vulnerable encryption algorithms include 3DES, RC4, and the message-digest algorithm (MD5). ### Ensure your certificates are issued by a trusted certificate authority Untrusted certificates cause errors in most browsers and often prevent users from accessing your site. Intentional use of self-signed or untrusted certificates should be done with extreme care to ensure both the accessibility and security of affected systems. ### Automate certificate renewal Prevent your SSL certificate from [lapsing due to expiration](https://www.upguard.com/blog/what-is-ssl-certificate-expiration) by setting up an automated renewal cycle. ### Route all traffic through HTTPS Enforce an [HTTP Strict Transport Security (HSTS)](https://www.upguard.com/blog/hsts) policy so that all site traffic uses a secure connection, thus preventing site lookalikes through SSL stripping. To serve traffic over HSTS, you may need to update your configuration files with additional directives and timeout settings. If you use Apache as your [proxy server](https://www.upguard.com/blog/proxy-server), you will need to update the \[.rt-script].htaccess\[.rt-script] file with a header that sets HSTS routing. For other proxy servers, you may need to update any config or template files for the secure routing. ### Protect your SSH connections If you provide any routes for SSH (secure shell) connection, it is important to ensure those are not vulnerable to encryption-breaking. Your SSH connections should not be external, as only your internal team should be using SSH to run commands on your server. As you consider your cipher suites, you may wish to consider how the digital signature authentication is set. Many cipher suites use either the RSA (Rivest-Shamir-Adleman) algorithm or ECDSA (Elliptic Curve Digital Signature Algorithm), which both have advantages and disadvantages. ### How UpGuard Can Help Current UpGuard users can [log in and access their Risk Profile in Breach Risk](https://cyber-risk.upguard.com/risk_profile) to assess whether any of the SSL findings referenced in this article are impacting external assets. You can also evaluate common SSL findings related to [missing certificates](https://www.upguard.com/blog/what-is-the-ssl-not-available-risk) and [certificates that have expired](https://www.upguard.com/blog/what-is-ssl-certificate-expiration). Once you have identified security concerns, you can [manage your remediation process](https://help.upguard.com/en/articles/3833873-how-to-manage-internal-remediation-requests-with-upguard) within UpGuard as well. You can reach out to our support team to investigate and verify any SSL findings that have been identified for your assets. If you're not a current UpGuard user and you want to review your public-facing assets for these findings and more, [sign up for a trial](https://www.upguard.com/demo). eBook A Complete Guide to Data Breaches Free resource ### A Complete Guide to Data Breaches Learn how to avoid a costly data breach with a comprehensive prevention strategy. [Download now](/resources/complete-guide-to-data-breaches) ## Related posts Learn more about the latest issues in cybersecurity. Risks and Vulnerabilities #### [25 Security Vulnerabilities That Have Defined the 2020s (Thus Far)](/blog/top-25-security-vulnerabilities-of-the-2020s) From Log4j to SolarWinds, discover the 25 critical security vulnerabilities that have reshaped cybersecurity thus far in the 2020s. [](/team/nicholas-sollitto) [Nicholas Sollitto](#) May 28, 2026 Risks and Vulnerabilities #### [ServiceNow Vulnerabilities: CVE-2024-4789 and CVE-2024-5217](/blog/servicenow-vulnerabilities) Learn about two critical vulnerabilities affecting the ServiceNow platform (CVE-2024-4789 and CVE-2024-5217) and how UpGuard can help. [](/team/nicholas-sollitto) [Nicholas Sollitto](#) January 16, 2025 Risks and Vulnerabilities #### [PHP2Shell: A Clear Explanation and Response Framework](/blog/php2shell-a-clear-explanation-and-response-framework) PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets unauthenticated attackers run code on PHP servers. Learn who’s affected and how to respond. [](/team/upguard) [UpGuard Team](#) October 21, 2026 Risks and Vulnerabilities #### [Everything Everywhere: Systemic Data Exposure in Supabase Apps](/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps) Supabase is a favorite of AI coding agents. It's also prone to misconfiguration. We studied more than 16,000 open databases to see what's leaking. [](/team/greg-pollock) [Greg Pollock](#) October 14, 2026 Risks and Vulnerabilities #### [Oracle Just Shipped 1,449 Security Patches in One Quarter. We Checked How Much of It Is Actually New.](/blog/oracle-just-shipped-1-449-security-patches-in-one-quarter-we-checked-how-much-of-it-is-actually-new) Oracle's July 2026 update shipped 1,449 security patches — 2.8x its all-time record. We parsed 23 quarters of advisories to find out how much is truly new. [](/team/greg-pollock) [Greg Pollock](#) July 22, 2026 Risks and Vulnerabilities #### [Data leakage risks with DBHub MCP servers](/blog/data-leakage-risks-with-dbhub-mcp-servers) UpGuard found exposed DBHub servers leaking live databases to the open internet—an early sign that MCP exposure is becoming a systemic data risk. [](/team/greg-pollock) [Greg Pollock](#) October 13, 2026 [All posts](/blog) Experience superior visibility and a simpler approach to cyber risk management [Get a demo](/contact-sales) [Free trial](/demo)