The WordPress root certificate bundle still ships 1024-bit certificates, and it has for more than a decade. The core team is now proposing to strip them out ahead of WordPress 7.0, which is scheduled for April 2026.
If you run high-traffic WooCommerce stores or larger enterprise installs, you already trade performance against security most weeks. Keeping 1024-bit certificates in ca-bundle.crt is a security problem, and it is also a stack pinned in place by CentOS 7 and the buggy OpenSSL builds of 2016.
Why 1024-bit certificates are a security risk
NIST disallowed 1024-bit RSA keys back in 2013. They sit well within reach of ordinary computing power, and browsers and operating systems purged them long ago. WordPress held on to support a narrow set of server environments, mainly CentOS 7.
CentOS 7 reached end of life in mid-2024, so that argument is gone. If your host still needs 1024-bit RSA to complete an SSL handshake, that is a liability rather than a quirk you can keep living with.
I wrote earlier about navigating the road to WordPress 7.0, and this cleanup belongs to the same transition. A smaller bundle means less overhead on WP_Http requests, and it stops WordPress from quietly accepting weaker security on outbound calls.
The technical impact on WP_Http
WordPress falls back to its own bundle at wp-includes/certificates/ca-bundle.crt when PHP’s openssl.cafile is not configured properly, or when a transport filter sends it there. Every outbound wp_remote_get() call verifies the remote server against that file. Take the 1024-bit certificates out and WordPress requires a higher encryption standard from every service it talks to.
<?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 something will break, check your server’s OpenSSL version first. On OpenSSL 1.1.1 or 3.x you are already issuing 2048-bit or 4096-bit keys for your own certificates, so nothing changes there. The change only touches the verification of remote servers still running something older.
If the 1024-bit certificates cleanup is eating your dev hours, I can take it on. I have been working with WordPress since the 4.x days.
What this means for the sites you run
WordPress is picking modern infrastructure over indefinite backward compatibility here. For developers that means fewer strange bugs traced back to a weak SSL handshake, and for site owners it means lining up with current NIST guidance. There is not much left to gain from keeping 2016-era server builds working.
