We need to talk about 1024-bit certificates. For over a decade, the WordPress root certificate bundle has carried legacy baggage that should have been dumped years ago. Specifically, the core team is finally proposing to strip these insecure certificates in preparation for WordPress 7.0, scheduled for April 2026.
If you have been managing high-traffic WooCommerce stores or complex enterprise installs, you know that performance and security are a balancing act. However, keeping 1024-bit certificates in the ca-bundle.crt file isn’t just about security anymore; it’s about modernizing a tech stack that has been held back by CentOS 7 and buggy OpenSSL versions from 2016.
Why 1024-bit Certificates are a Security Risk
The National Institute of Standards and Technology (NIST) disallowed the use of 1024-bit RSA keys way back in 2013. These keys are mathematically vulnerable to modern computational power. Furthermore, most modern browsers and operating systems have already purged them. WordPress kept them around to support a very narrow range of server environments—primarily CentOS 7.
Consequently, with CentOS 7 hitting End of Life (EOL) in mid-2024, there is no technical justification for keeping these weak links in the WordPress root certificate bundle. If your host is still running on hardware that requires 1024-bit RSA for SSL handshakes, you aren’t just dealing with legacy code; you’re dealing with a liability.
I’ve written before about navigating the road to WordPress 7.0, and this cleanup is a vital part of that transition. Stripping the bundle reduces the overhead during WP_Http requests and ensures that WordPress doesn’t inadvertently downgrade security for outbound API calls.
The Technical Impact on WP_Http
WordPress uses an internal bundle (wp-includes/certificates/ca-bundle.crt) when PHP’s openssl.cafile isn’t properly configured or when specific transport filters are applied. When you make an outbound request via wp_remote_get(), WordPress verifies the remote server against this bundle. By removing the 1024-bit certificates, WordPress effectively forces a higher standard of encryption for any service it communicates with.
<?php
/**
* Example: How to check the SSL bundle version in your environment.
* Pragmatic tip: Always ensure your server's OpenSSL is current.
*/
function bbioon_check_ssl_context() {
$bundle_path = ABSPATH . WPINC . '/certificates/ca-bundle.crt';
if ( file_exists( $bundle_path ) ) {
// Log the file size or hash to monitor core updates
error_log( 'WP CA Bundle size: ' . filesize( $bundle_path ) );
}
}
add_action( 'admin_init', 'bbioon_check_ssl_context' );
If you are worried that your site might break, check your server’s OpenSSL version. If you are on OpenSSL 1.1.1 or 3.x, you are already using 2048-bit or 4096-bit keys for your own certificates. This change only affects the verification of remote servers that might still be using dangerously outdated tech.
Look, if this 1024-bit certificates stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway: Ship More Secure Code
This update is a clear signal that WordPress is prioritizing modern infrastructure over infinite backward compatibility. For developers, this means fewer edge-case bugs caused by weak SSL handshakes. For business owners, it ensures that your site complies with modern security standards like those from NIST. It’s time to stop supporting 2016’s problems in 2026.
