PayPal Requires TLS 1.2
Overview
To maintain compliance with the Payment Card Industry Data Security Standard (PCI DSS), PayPal APIs reject all HTTP connections utilizing protocols older than TLS 1.2.
While TLS 1.2 remains the strict minimum requirement, TLS 1.3 is the modern cryptographic standard. PayPal fully supports TLS 1.3 on both Sandbox and Live environments. Upgrading your infrastructure to prioritize TLS 1.3 is highly recommended for reduced handshake latency and improved cryptographic security.
If your web server, application environment, or operating system attempts to negotiate a connection to PayPal endpoints using TLS 1.0 or TLS 1.1, the connection will be forcefully dropped.
1. Operating System Compatibility Matrix
Modern operating systems support both TLS 1.2 and TLS 1.3 natively. Legacy operating systems may require manual configuration or are entirely unsupported.
Linux Distributions
- Red Hat Enterprise Linux (RHEL) / AlmaLinux / Rocky Linux
- Versions 8 & 9: Natively support TLS 1.2 and TLS 1.3. No action required.
- Version 7: Natively supports TLS 1.2. (Note: RHEL 7 reached EOL in June 2024).
- Versions 5 & 6: Unsupported. You must migrate to a modern release.
- Ubuntu
- 20.04 LTS, 22.04 LTS, & 24.04 LTS: Natively support TLS 1.2 and TLS 1.3. No action required.
- 14.04 LTS & 16.04 LTS: Natively support TLS 1.2.
- Debian
- 11 (Bullseye) & 12 (Bookworm): Natively support TLS 1.2 and TLS 1.3. No action required.
- 10 (Buster): Natively supports TLS 1.2 and TLS 1.3.
Windows Server
- Windows Server 2022 & 2025: Natively support and prioritize TLS 1.3 and TLS 1.2. No action required.
- Windows Server 2016 & 2019: Natively support TLS 1.2 by default.
- Windows Server 2012 / 2012 R2: Supports TLS 1.2, but relies heavily on the .NET framework version installed (requires .NET 4.6.2+ for native default negotiation).
- Windows Server 2008 & Older: Unsupported. Must migrate to a modern Windows Server environment.
2. Application & Framework Requirements
Even if your OS supports TLS 1.2/1.3, your application runtime must be configured to utilize it. Ensure your environments meet the following minimums:
- Java: Java 8 (JDK 1.8) defaults to TLS 1.2. Java 11+ supports TLS 1.3.
- PHP: Requires cURL 7.34.0+ and OpenSSL 1.0.1+ (OpenSSL 1.1.1+ is required for TLS 1.3).
- Python: Python 3.4+ natively supports TLS 1.2. Python 3.7+ (compiled with OpenSSL 1.1.1+) supports TLS 1.3.
- Node.js: Node v10+ defaults to TLS 1.2. Node v12+ natively supports TLS 1.3.
- .NET Framework: Must be running .NET 4.6.2 or higher to default to OS-level TLS settings. Versions 4.5 and 4.6 require explicit protocol definitions in the code (e.g.,
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;).
3. Verifying Endpoint Connectivity
Before deploying code, test your server's outbound connection to PayPal's API endpoints. It is recommended to test against the Sandbox endpoint first.
PayPal API Endpoints:
- Sandbox:
api.sandbox.paypal.com - Live:
api.paypal.com
For Linux (Using cURL)
Run the following command to force a TLS 1.2 connection to PayPal:
curl -v -I --tlsv1.2 https://api.sandbox.paypal.comExpected Output: Look for SSL connection using TLSv1.2 or TLSv1.3. Receiving an HTTP 200 OK or 401 Unauthorized confirms the TLS handshake succeeded.
For Linux (Using OpenSSL)
To explicitly test the handshake layer without sending an HTTP payload:
openssl s_client -connect api.sandbox.paypal.com:443 -tls1_2(You can replace -tls1_2 with -tls1_3 on modern systems to verify TLS 1.3 negotiation).
For Windows (Using PowerShell)
Run the following in PowerShell to force TLS 1.2 and attempt a connection:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri "https://api.sandbox.paypal.com" -UseBasicParsingExpected Output: A successful return object indicates the TLS connection was established. If it fails with "Could not create SSL/TLS secure channel", the system requires patching or registry configuration.
4. Enforcing TLS 1.2 via Windows Registry (Legacy Systems)
For legacy Windows Server environments (e.g., 2012 R2) where TLS 1.2 is not negotiating by default, you must forcefully enable it at the SChannel level.
Run the following script in PowerShell as Administrator, then reboot the server:
# Enable TLS 1.2 for Client and Server SChannel
$path = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2"
If (!(Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
$serverPath = "$path\Server"
If (!(Test-Path $serverPath)) { New-Item -Path $serverPath -Force | Out-Null }
New-ItemProperty -Path $serverPath -Name "Enabled" -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $serverPath -Name "DisabledByDefault" -Value 0 -PropertyType DWORD -Force | Out-Null
$clientPath = "$path\Client"
If (!(Test-Path $clientPath)) { New-Item -Path $clientPath -Force | Out-Null }
New-ItemProperty -Path $clientPath -Name "Enabled" -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $clientPath -Name "DisabledByDefault" -Value 0 -PropertyType DWORD -Force | Out-Null
# Force .NET Framework to use strong cryptography
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value 1 -Type DWord
Set-ItemProperty -Path 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value 1 -Type DWord
Write-Host "Registry updated. Restart the server to apply changes." -ForegroundColor GreenUpdated 6 days ago