What removing an SSL certificate from Apache changes
Removing an SSL certificate from Apache means deleting the 443 virtual host, removing the certificate paths from it, then reloading the service. On Ubuntu disable the site with a2dissite, delete a Let's Encrypt certificate with certbot delete, test with apachectl configtest and reload. It worked when http:// serves the site and https:// no longer completes a handshake.
Three things move together: the VirtualHost *:443 block, the SSLCertificateFile and SSLCertificateKeyFile lines inside it, and the certificate files on disk. The port 80 virtual host is untouched, so the same document root keeps serving over plain HTTP.
- Port 443 stops answering once no virtual host on that port holds a certificate.
- Port 80 keeps the same document root, so pages and URLs survive the change.
- Chrome and Firefox label the site Not secure, and the padlock disappears from search results.
- The certificate stays valid until it expires or the issuing CA revokes it.
For a staging host or an internal tool this is the right edit. For a site that takes logins, payments or search traffic, keep the SSL certificate and fix the misconfiguration instead.
Remove the 443 virtual host on Ubuntu or Debian
Apache 2.4 on Ubuntu 22.04 or 24.04 keeps sites in /etc/apache2/sites-available and enables them with a symlink. Certbot writes the TLS copy as example.com-le-ssl.conf. Disable that file rather than deleting it, because re-enabling is then a single command.
- List the enabled sites: ls /etc/apache2/sites-enabled/. The TLS entry normally ends in -le-ssl.conf.
- Keep a copy: sudo cp /etc/apache2/sites-available/example.com-le-ssl.conf ~/example.com-le-ssl.bak.
- Disable the site: sudo a2dissite example.com-le-ssl.conf. Apache confirms the site is disabled.
- Test before reloading: sudo apachectl configtest. Wait for Syntax OK.
- Reload, do not restart: sudo systemctl reload apache2. Open connections stay up.
- Run the curl pair in the verification section. HTTPS should now fail.
If the vhost was written by hand instead of by certbot, comment out the whole VirtualHost block in the .conf file and leave the port 80 block alone. Reload and check the same way.
Remove the certificate on RHEL, AlmaLinux or Rocky
RHEL-family systems keep virtual hosts in /etc/httpd/conf.d, and the mod_ssl package ships a default ssl.conf that listens on 443. That file is the usual reason HTTPS still answers after the site's own vhost is gone.
- Find every block that loads a certificate: sudo grep -rl SSLCertificateFile /etc/httpd/conf.d/.
- Back up the site file: sudo cp /etc/httpd/conf.d/example.com.conf ~/example.com.conf.bak.
- Delete or comment the VirtualHost *:443 block and keep the port 80 block.
- If ssl.conf exists only for this site, move it out of the way: sudo mv /etc/httpd/conf.d/ssl.conf /root/ssl.conf.disabled.
- Run sudo apachectl configtest, then sudo systemctl reload httpd.
- Close the firewall port when nothing else uses it: sudo firewall-cmd --remove-service=https --permanent, then sudo firewall-cmd --reload.
On RHEL 9, AlmaLinux 9 and Rocky 9 the service is httpd, not apache2. A reload that answers Unit apache2.service not found is a naming mistake in the command, not a certificate fault.
Delete the Let's Encrypt certificate so certbot stops renewing it
Disabling the virtual host leaves certbot's renewal configuration active, so the systemd timer keeps requesting a certificate for a host that no longer serves TLS. Remove it through certbot instead of deleting folders by hand.
Run sudo certbot certificates to read the exact certificate name, then sudo certbot delete --cert-name example.com. That single command removes /etc/letsencrypt/live/example.com, the archive copies and the renewal file. Rerun certbot certificates and confirm the entry is gone.
Deleting the files does not revoke the certificate. A public CA certificate remains valid until expiry, and anyone holding the private key can still present it. If the key leaked, ask the issuing CA to revoke the certificate as well.
Verify HTTP still loads and HTTPS stops answering
Two commands settle it from any machine. Run curl -I http://example.com and expect a 200, or a 301 that stays on http. Then run curl -Ik https://example.com. With nothing listening on 443 the second command fails with connection refused or an SSL error, and that failure is the proof the removal worked.
In a browser, open the site in a private window. You know it worked when the page renders without a padlock and the address still starts with http://. If the browser switches to https on its own, a redirect rule or a cached HSTS entry is still forcing it, which the next section covers.
Why HTTPS still answers after you remove the certificate
Apache serves one listener per port, so any remaining 443 virtual host can answer for the whole server. Match the symptom to the cause before editing another file.
| Symptom | Cause | Fix |
|---|---|---|
| https:// still presents a certificate | Another 443 vhost or ssl.conf is the default listener | Run apachectl -S, find the first 443 entry, disable that file |
| The browser switches to https by itself | Redirect rule in .htaccess or the port 80 vhost | Remove the RewriteRule or Redirect line, then reload |
| Chrome refuses http:// with no way to continue | HSTS cached from the old HTTPS setup | Clear it at chrome://net-internals/#hsts, then retest |
| configtest fails with Invalid command SSLEngine | ssl module disabled while a 443 vhost remains | Run a2enmod ssl again, or delete the leftover vhost |
| ERR_CONNECTION_REFUSED on https:// | Nothing listens on 443 | Expected result: the removal is complete |
When removing SSL is the wrong move
Public sites should keep TLS. Chrome shows a Not secure warning on plain HTTP, passwords and form posts travel in clear text, and referral data is lost in analytics. Removing a certificate fixes none of that.
The legitimate cases are narrow: a staging copy behind a VPN, an internal admin panel on a private network, or a migration where the old server still holds the certificate. The work needs root, which a WebJi VPS gives you and shared hosting does not; on shared hosting the certificate is managed from the panel.
If the complaint is a warning rather than a certificate, read why browsers show Not secure before you remove anything.
Frequently Asked Questions
How do I remove an SSL certificate from Apache?
Disable or delete the VirtualHost block that listens on 443 and holds the SSLCertificateFile lines. Run apachectl configtest, then reload Apache. If Let's Encrypt issued the certificate, run certbot delete --cert-name example.com. Confirm with curl -I on http and curl -Ik on https; the HTTPS request should fail.
Does deleting the certificate files revoke the certificate?
No. Removing the files from /etc/letsencrypt or any other folder stops your server presenting the certificate, but it stays valid until its expiry date. Ask the issuing CA to revoke it when the private key may have leaked.
Why does https still work after I removed the virtual host?
Another virtual host or the package ssl.conf is still listening on port 443. Run apachectl -S to see which configuration file owns that port, disable it, then reload. A cached HSTS entry in the browser can also keep forcing HTTPS.
How do I stop certbot renewing a deleted certificate?
Run sudo certbot delete --cert-name example.com. It removes the live and archive copies plus the renewal configuration, so the timer has nothing left to renew. Check the remaining list with certbot certificates.
Will removing SSL hurt SEO?
Yes, on a public site. HTTPS is a confirmed ranking signal, Chrome labels plain HTTP as Not secure, and referral data is lost. Keep the certificate in production and remove it only on staging or internal hosts.
Can I put the certificate back after removing it?
Yes. Re-enable the saved virtual host with a2ensite or restore the backup file, then reload Apache. If the old Let's Encrypt certificate expired, issue a new one with certbot --apache -d example.com.