Skip to content

ERR_SSL_RENEGOTIATION_NOT_SUPPORTED

Key idea:

ERR_SSL_RENEGOTIATION_NOT_SUPPORTED — server requested renegotiation (rekey), but the client (or protocol) does not support it. TLS 1.3 removed renegotiation entirely (security issue). If the server still initiates, downgrade to TLS 1.2 or (better) remove the renegotiation logic. Typical in mTLS/client-auth workflows.

This error blocks HTTPS access. Below: causes, fixes, working config, FAQ.

Check your site's SSL →

Common Causes

  • TLS 1.3 removed renegotiation — server still tries
  • mTLS (client-auth): server requests cert after handshake via re-neg
  • Legacy Java applications with renegotiation-based key refresh
  • Apache + SSLVerifyClient require inside
  • Old JVM (

Step-by-Step Fix

  1. TLS 1.3: move to post-handshake authentication (RFC 8446)
  2. TLS 1.2 + mTLS: request clientauth at port/host level, not via re-neg
  3. nginx + mTLS: ssl_verify_client optional_no_ca; ssl_client_certificate
  4. Remove renegotiation from client pool/library settings
  5. Update client Java/OpenSSL/curl to TLS 1.3 support

Check SSL Certificate →

Related SSL Errors

TL;DR: Understanding ERR_SSL_RENEGOTIATION_NOT_SUPPORTED

The ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error indicates that the server does not support TLS renegotiation, a security feature used to negotiate a new session key during an existing TLS session. This can lead to failed connections, particularly in browsers like Chrome or Firefox. Fixing this error generally involves updating server configurations to allow renegotiation or ensuring that the server's TLS settings comply with modern standards such as RFC 5246.

What Causes ERR_SSL_RENEGOTIATION_NOT_SUPPORTED?

The ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error typically arises from server configurations that restrict TLS renegotiation due to security concerns. TLS renegotiation allows a client and server to negotiate new session parameters without requiring a full handshake. However, not all servers are configured to support this feature, which can lead to the error when clients attempt to renegotiate:

  • Server Configuration: If the server is configured to reject renegotiation requests, clients will encounter this error.
  • Outdated Software: Older versions of web servers or SSL libraries may not fully support modern TLS renegotiation standards.
  • Client-Side Issues: Sometimes, the error may arise from specific browser settings or extensions that block renegotiation attempts.

To resolve the issue, administrators must analyze server logs to identify the source of the error and ensure that the server is configured to support secure renegotiation.

How to Fix ERR_SSL_RENEGOTIATION_NOT_SUPPORTED

To address the ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error, follow these steps:

  1. Update Your Server Software: Ensure that your web server software (e.g., Apache, Nginx) and SSL/TLS libraries (OpenSSL) are up to date. Use the commands below depending on your server type:
# For Ubuntu/Debian systems
sudo apt update
sudo apt upgrade
# For CentOS/RHEL systems
sudo yum update
  1. Enable TLS Renegotiation: Modify your server configuration files to allow secure TLS renegotiation. For example, in Nginx, include the following in your server block:
ssl_renegotiation on;
  1. Configure SSL Parameters: Ensure that the SSL parameters comply with RFC 5746 to support secure renegotiation. For example, in Apache, add the following lines to your configuration:
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite HIGH:!aNULL:!MD5
  1. Test SSL Configuration: Use tools like SSL Labs' SSL Test to verify that your server supports secure renegotiation. This can help identify any remaining issues.

By following these steps, you can effectively resolve the ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error and ensure secure communications between clients and your server.

TL;DR: Understanding ERR_SSL_RENEGOTIATION_NOT_SUPPORTED

The ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error indicates that a web server does not support TLS renegotiation, a security feature that allows a client and server to renegotiate the parameters of an existing TLS connection. This can occur due to server configuration or outdated software. To resolve this issue, ensure that your server is configured to support TLS renegotiation according to RFC 5746 and that your SSL/TLS library is up to date.

Technical Overview of TLS Renegotiation

TLS renegotiation is a process that allows a client and server to negotiate new session parameters without terminating the existing connection. This can be useful for updating cryptographic keys or altering session attributes. However, the ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error arises when a server does not support this feature, typically due to security configurations or outdated software libraries.

In 2009, the renegotiation attack vulnerability was discovered, leading to the introduction of RFC 5746, which defines secure renegotiation. Compliance with this RFC is crucial for maintaining secure connections. The error often indicates that the server is not configured to allow renegotiation or that the client is using a browser that does not support the server's SSL/TLS configuration.

To check if your server supports TLS renegotiation, you can use tools like openssl. Here’s a command you can run from your terminal:

openssl s_client -connect yourdomain.com:443 -tlsextdebug

If renegotiation is supported, you will see a response indicating the TLS extensions being used. If not, you may need to review your server configuration.

In summary, understanding the nuances of TLS renegotiation is essential for troubleshooting the ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error. Ensure your server is compliant with RFC 5746 and that all software components are current to mitigate this issue.

Configuring Your Server for TLS Renegotiation

To fix the ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error, you must configure your web server to enable TLS renegotiation. This process varies depending on the server software you are using. Below are configuration examples for Apache and Nginx, two widely used web servers.

Apache Configuration

For Apache, you need to ensure that the SSLProtocol directive includes support for TLS 1.2 or higher. You can do this by editing your Apache configuration file (usually located at /etc/httpd/conf/httpd.conf or /etc/apache2/sites-available/default-ssl.conf). Add or modify the following lines:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

Additionally, ensure that the SSLRenegBufferSize directive is set to a value greater than zero:

SSLRenegBufferSize 1048576

After making these changes, restart Apache to apply the configuration:

sudo systemctl restart apache2

Nginx Configuration

For Nginx, you can enable TLS renegotiation by ensuring that the ssl_protocols directive includes at least TLS 1.2. Edit your Nginx configuration file (typically located at /etc/nginx/nginx.conf or /etc/nginx/conf.d/default.conf) and include the following:

ssl_protocols TLSv1.2 TLSv1.3;

To check if renegotiation is enabled, you can add the ssl_renegotiation directive within your server block:

ssl_renegotiation on;

After saving your changes, restart Nginx:

sudo systemctl restart nginx

By ensuring that your server is properly configured to support TLS renegotiation, you can resolve the ERR_SSL_RENEGOTIATION_NOT_SUPPORTED error and enhance the security of your web application.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

Frequently Asked Questions

What is TLS renegotiation?

A process during an active TLS session where parties renegotiate keys/cipher/auth without tearing down the connection. TLS 1.3 replaced it with post-handshake auth.

Why was renegotiation removed?

Vulnerable to attack (CVE-2009-3555 renegotiation MITM). TLS 1.3 uses KeyUpdate and post-handshake auth — safer replacement.

How to set up mTLS in 2026?

For TLS 1.3: server sends CertificateRequest in handshake, client answers. No renegotiation. Nginx supports.

Legacy Java client — what to do?

Upgrade to Java 17+ (TLS 1.3 support). Or keep TLS 1.2 for this endpoint + set up mTLS correctly.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.