Remove an SSL Certificate From Apache
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.
For admins turning off HTTPS on an Apache staging or internal host, on Ubuntu or RHEL-family systems.
knowledge
- Read time
- 4 min
- Sections
- 7
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 15 November 2026.
What removing an SSL certificate from Apache changes
Removing an SSL certificate from Apache means taking away the VirtualHost *:443 block, its SSLCertificateFile lines, and the certificate files on disk — while the port 80 virtual host keeps serving the same document root. Nothing else about the site changes.
- 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
- Browsers: 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
On Ubuntu 22.04 or 24.04, disable the TLS site file with a2dissite rather than deleting it, so re-enabling stays a single command. Apache 2.4 keeps sites in /etc/apache2/sites-available, enabled through a symlink in sites-enabled, and certbot writes the TLS copy as example.com-le-ssl.conf.
- 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 configtestand wait forSyntax OK - Reload, do not restart:
sudo systemctl reload apache2so 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, leave the port 80 block alone, and reload the same way.
Remove the certificate on RHEL, AlmaLinux or Rocky
RHEL-family systems keep virtual hosts in /etc/httpd/conf.d, and mod_ssl 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, thensudo systemctl reload httpd. - Close the firewall port when nothing else uses it:
sudo firewall-cmd --remove-service=https --permanentthensudo 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 use certbot delete instead of removing folders by hand. The Certbot documentation warns never to delete files inside /etc/letsencrypt manually — the subcommand cleans up everything related to the certificate in one step.
sudo certbot certificates
sudo certbot delete --cert-name example.comThe delete command removes /etc/letsencrypt/live/example.com, the archive copies and the renewal file, and it is irreversible. 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 it as well. The nginx equivalent of this whole workflow is in issuing an SSL certificate with certbot on nginx.
Verify HTTP still loads and HTTPS stops answering
Two curl commands settle it from any machine: HTTP should answer, and the HTTPS request should fail.
curl -I http://example.com
curl -Ik https://example.comExpect a 200 on the first (or a 301 that stays on http). With nothing listening on 443 the second 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: the page should render without a padlock and the address should start with http://. If the browser switches to https on its own, a redirect rule or a cached HSTS entry is still forcing it — the next section covers both.
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.
This 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 removing anything, and the reverse procedure is in installing an SSL certificate on Apache.
Frequently asked questions
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.
Last editorial update: 15 November 2026. Prices follow the dated sources on this page; checkout confirms current charges.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.