Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Use one SAN certificate for names that share a lifecycle, or issue separate certificates when each Apache virtual host needs independent renewal and failure isolation. In either design, every DNS name must reach the Apache host that serves its ACME challenge: HTTP-01 requires an reachable port 80, while DNS-01 proves control with a DNS TXT record. The reliable workflow is to inventory each vhost, issue certificates with correctly grouped webroots, inspect Apache’s generated configuration, verify every name, and test automated renewal before relying on it.
How certificates map to Apache virtual hosts
A certificate covers DNS names, not Apache configuration files. One certificate can contain several names as Subject Alternative Names (SANs), such as example.com, www.example.com, and shop.example.com. Alternatively, each site can have its own certificate. Certbot supports both approaches.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choose the arrangement according to operational boundaries rather than the number of vhost files:
| Approach | Best fit | Advantages | Trade-offs |
|---|---|---|---|
| One SAN certificate | Names share an owner, deployment, and renewal schedule | Fewer certificates and one renewal transaction | A name change or failed validation affects the whole certificate; the certificate has a larger blast radius |
| Separate certificate per vhost | Sites have different owners, roots, schedules, or risk tolerance | Renewal failures and configuration changes are isolated | More certificate records, challenge paths, and Apache directives to monitor |
Apache mod_md |
You want Apache itself to manage ACME provisioning and renewal | Certificate lifecycle is native to Apache-managed domains | Module behavior and packaging depend on your Apache version and distribution; it is a different operating model from Certbot |
Do not put unrelated customer or administrative domains into a single SAN certificate merely to reduce file count. A mistake, revoked certificate, or ownership change then affects every name in that certificate. Conversely, a single SAN request is convenient for aliases that always deploy together: one successful validation and one renewal transaction cover all of them. Consider the blast radius if one name later moves to another provider, changes its webroot, or must be renewed under a different DNS account.
Inventory every virtual host before requesting a certificate
Create a small record for each site. This prevents Certbot from writing a challenge file into a directory that Apache does not actually serve. Include the exact spelling of every public name; a certificate for www.example.com does not cover example.com unless both are requested.
- Fully qualified
ServerNameand everyServerAlias. - The HTTP virtual host on port 80 and its
DocumentRoot(or the webroot used by the application). - The HTTPS virtual host on port 443, if one already exists.
- The certificate name you want Certbot to display and renew.
- Public DNS A and AAAA records, including whether IPv6 reaches this same server.
- Firewall, load-balancer, and NAT rules for port 80 (and port 443 for normal HTTPS traffic).
- Any authentication, rewrite, proxy, or access-control rule that could block
/.well-known/acme-challenge/.
Every requested name must resolve to the machine that answers its challenge. A stale A record, an AAAA record pointing elsewhere, or a default Apache vhost can make validation reach the wrong site even when the certificate request is correct. If a load balancer terminates HTTP, ensure it forwards the challenge unchanged to the host running Certbot, or perform validation at the layer that controls the public name.
Write down which names share a root and which do not before constructing a command. This simple map also becomes a useful renewal runbook: when a document root, proxy, DNS provider, or firewall changes, you know exactly which certificate and vhost require a dry run.
Choose the ACME validation method
HTTP-01 with the Apache plugin
Certbot’s Apache plugin can authenticate a name and install the certificate by editing Apache configuration. It expects an already-running HTTP site and uses port 80 for the challenge. This is convenient when Certbot is allowed to alter vhost files, redirects, and SSL directives. Read the resulting configuration and preserve it in your normal configuration-management process; an automated installer does not know every local policy or proxy rule.
HTTP-01 with the webroot plugin
The webroot plugin leaves Apache configuration under your control. Certbot writes a temporary token beneath /.well-known/acme-challenge/ in the selected webroot; Apache must serve that exact directory publicly. Use this when you manage vhost files yourself, use a configuration-management system, or need predictable changes. The challenge directory must remain available for later renewals, not just for the first issuance.
DNS-01
DNS-01 proves control by creating a TXT record. It is the alternative when port 80 cannot be exposed, when a service is not publicly reachable over HTTP, or when you need wildcard names. Use a supported DNS automation plugin or another controlled DNS workflow, and account for propagation time. Limit DNS API credentials to the required zones and protect them like private keys. DNS validation does not remove the need to configure Apache with the resulting certificate.
Recommended Free Tools
In 2026, the Let’s Encrypt announcement notes that the Apache and nginx plugins do not yet support certificates for IP addresses. An IP-only deployment therefore needs a different validation and certificate path; a hostname-based certificate remains the normal Apache solution.
Install and check Certbot
Install Certbot and its Apache integration using the package method documented for your Linux distribution or the Certbot project. Package names, module locations, and service names vary, so do not copy an Ubuntu-specific command onto another operating system. Confirm the executable before changing production configuration:
certbot --versionThe Apache plugin acts as both an authenticator and an installer. The webroot plugin is an authenticator only when used with certonly; you then wire the certificate into Apache yourself. Keep the Certbot version in your patching plan, because renewal behavior and available commands can change between releases.
Rank #2
- Used Book in Good Condition
Issue certificates for several sites
One site with aliases
For a single vhost and its aliases, the concise Apache-plugin form is:
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minutesudo certbot --apache -d example.com -d www.example.comReview the proposed names and redirect changes. Certbot may create or modify the SSL vhost; inspect that result rather than assuming it matches your preferred layout. If an alias is not intended to answer on this server, leave it out instead of allowing validation to fail for the complete SAN request.
Several names that share one webroot
When all names are served from the same document root, include them in one request:
sudo certbot certonly --webroot
-w /var/www/example
-d example.com -d www.example.com -d shop.example.comCertbot places the challenge token under that webroot, and Apache must route every listed name to it on port 80. Test each name independently; a shared directory does not guarantee that vhost matching is shared.
Different roots in one request
Repeat -w before each group of names that uses a different root:
sudo certbot certonly --webroot
-w /var/www/example -d example.com -d www.example.com
-w /var/www/api -d api.example.netCertbot assigns each following -d name to the most recently specified webroot path. The ordering is therefore significant: put -w immediately before the names whose HTTP vhost serves that directory. A misplaced option commonly produces an HTTP-01 404 because the token was written somewhere Apache does not expose. If two names use different roots, issue separate requests or keep their groups explicit rather than relying on an implicit default.
Separate certificates per vhost
Run an independent request for each site, choosing either --apache or certonly --webroot. Separate certificates make ownership and failure boundaries clear. Record the resulting certificate name because it is used by renewal inspection and by the live symlink directory. The number of certificates is not itself a problem; the important requirement is that every renewal configuration still points at a reachable challenge location.
Wire a webroot certificate into Apache
With --apache, Certbot normally adds the SSL directives for you. Read the generated vhost and confirm that the intended ServerName, aliases, and certificate files are together. With a webroot certonly request, edit the HTTPS vhost explicitly:
SSLCertificateFile /etc/letsencrypt/live/<certificate-name>/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/<certificate-name>/privkey.pemThe live directory contains symlinks that Certbot updates on renewal. Point Apache at these stable paths instead of copying a dated file from an archive directory. Protect the private-key file with the permissions expected by your Apache service account and do not expose it through a document root or backup share.
Enable the SSL module and the intended site using the mechanisms provided by your distribution, then validate and reload gracefully:
sudo apachectl configtest
sudo systemctl reload apache2The service unit may have a different name on your operating system. A successful configuration test is required before reload; a reload is required after certificate files change so worker processes begin serving the renewed certificate.
Keep the HTTP challenge location reachable during issuance and renewal. An HTTP-to-HTTPS redirect is generally compatible when it ultimately permits the challenge, but a rule that denies, authenticates, proxies, or rewrites /.well-known/acme-challenge/ to an unrelated application will fail validation. An explicit exception in the port-80 vhost is often the clearest design. Check both the filesystem permissions and Apache’s AllowOverride, Require, and rewrite behavior if the token returns an unexpected status.
Verify every name and the selected vhost
Do not test only the first hostname. For every ServerName and ServerAlias:
- Confirm DNS A and AAAA answers point to the intended server.
- Request the HTTP URL and ensure it reaches the expected port-80 vhost.
- Check that a file beneath
/.well-known/acme-challenge/would be readable without login or application routing. - Request HTTPS and inspect the presented certificate, including its subject names and expiration.
- Inspect Apache’s effective map of names and addresses:
sudo apachectl -SFor a quick HTTP status check, use:
curl -I http://example.com/.well-known/acme-challenge/testA temporary 404 is expected if the file does not exist; the important result is that the response comes from the intended vhost and is not an authentication challenge, redirect loop, or unrelated site. During a real issuance, Certbot creates the token and removes it afterward.
Duplicate ServerName or ServerAlias entries, vhost ordering, a default SSL vhost, and an IPv6 address pointing to another machine are common reasons a valid certificate appears on the wrong site. Also check whether a reverse proxy or CDN is answering port 80 before Apache sees the request. The challenge response must be consistent from every public address used by the name.
Automate renewal for all managed certificates
Certbot stores the authenticator and options used for each certificate. The renewal command evaluates every managed certificate and renews only certificates that meet the current readiness threshold:
sudo certbot renew --dry-run
sudo certbot renewMost installations schedule this command automatically, commonly through a systemd timer or cron entry. Verify the schedule on your distribution instead of assuming a particular unit name. Check logs and alerting as well as the timer: a scheduled command that cannot reach one vhost is still an operational failure.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
As of Certbot 4.0.0, a certificate is considered ready when less than one third of its lifetime remains. For certificates with a lifetime of 10 days or less, the threshold is one half of the lifetime. A normal renew run therefore does nothing for certificates that are not yet inside the applicable window.
Always perform a staging dry run after changing a document root, redirect, proxy, firewall, DNS, or vhost alias:
sudo certbot renew --dry-runDo not use --force-renewal as a routine test; unnecessary requests consume the certificate authority’s rate-limit budget. A dry run exercises the saved authenticator and renewal options without replacing the production certificate.
Changing renewal options
Certbot 2.3 and newer provide reconfigure for changing the saved renewal parameters and testing them against the staging server before committing the new configuration:
sudo certbot reconfigure --cert-name <name>Use the certificate name shown by certbot certificates. This is safer than manually editing renewal files without a test. Review each named renewal configuration when one site renews successfully but another does not; they may retain different webroots or redirect assumptions.
Reloading Apache after renewal
Some installations reload Apache automatically through Certbot’s installer. If yours does not, add a narrowly scoped deploy hook:
sudo certbot renew --deploy-hook "systemctl reload apache2"Verify the hook in a staging dry run and confirm that the service name matches your operating system. Without a reload, Apache can continue serving the old certificate even though Certbot has updated the symlinks. Keep the hook limited to the service that must reload, and ensure a failed configuration test prevents an unsafe reload.
Troubleshoot failures by symptom
| Symptom | Likely cause | Action |
|---|---|---|
| HTTP-01 returns 404 | The token was written to the wrong webroot, or the vhost’s document root is not the path used with -w |
Place /.well-known/acme-challenge/ in the directory actually served by that name and correct the -w ordering. |
| The challenge reaches another site | Duplicate aliases, default-vhost selection, or an IPv6 mismatch | Run apachectl -S, inspect A and AAAA records, and make the port-80 vhost explicit. |
| Only one site renews | A saved renewal configuration retained an old webroot, redirect, or proxy assumption | Run certbot certificates, inspect the named renewal settings, then use certbot reconfigure and a staging dry run. |
| HTTPS still shows the old certificate | Apache was not reloaded, or a different SSL vhost answered | Run apachectl configtest, reload gracefully, and verify the selected vhost and certificate paths. |
| Port 80 cannot be exposed | HTTP-01 is unsuitable for the network design | Use DNS-01 with a supported DNS automation plugin, or evaluate Apache mod_md. |
When Apache mod_md is a better fit
Apache’s mod_md provides native ACME provisioning and renewal for Apache-managed domains. It can be preferable when the web server should own the complete certificate lifecycle instead of delegating issuance and installation to Certbot. Evaluate it against your Apache version, distribution packaging, monitoring, and existing configuration-management practices. Confirm how the module exposes status and logs before migrating production domains.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall| Decision question | Certbot with SAN or separate certificates | mod_md |
|---|---|---|
| Who controls lifecycle? | Certbot and its saved renewal configuration | Apache itself |
| How are names grouped? | One SAN request or independent requests | Apache-managed domain groups |
| Where do failures appear? | Certbot logs, renewal records, and deploy hooks | Apache’s module status and logs |
| What changes when a name moves? | Adjust webroot or renewal options and test | Adjust Apache’s managed-domain configuration and test |
Choose one lifecycle owner for a given certificate. Do not have Certbot and mod_md compete to replace the same files or reload the same vhost. Mixing ownership makes it difficult to identify which tool changed a certificate and which logs explain a failure.
Production checklist
- Every requested DNS name resolves to the challenge-serving server over the records clients actually use, including IPv6.
- Port 80 is reachable for HTTP-01, or a tested DNS-01 process is in place.
- Each name’s challenge directory is publicly readable and bypasses authentication and destructive rewrites.
- Webroot groups in the Certbot command match the Apache document roots exactly.
- Apache’s generated or manually written SSL directives use the intended
live/<certificate-name>paths. apachectl configtestpasses before every reload.apachectl -Sshows one unambiguous vhost for each name and address.certbot renew --dry-runsucceeds after each routing, firewall, proxy, or DNS change.- A deploy hook reloads Apache when the installer does not, and that hook has been tested.
- Monitoring alerts on renewal failures and certificate expiry rather than waiting for browser warnings.
Frequently Asked Questions
Should every Apache virtual host have its own Let’s Encrypt certificate?
No. Put names that share an owner, webroot, deployment, and renewal schedule in one SAN certificate. Use separate certificates when sites have different owners, roots, risk tolerance, or failure boundaries.
Can one Certbot command use different document roots?
Yes. With the webroot plugin, repeat -w before each group of -d names. Every name uses the most recently specified webroot, so option order must match the vhost that serves each name.
Why does Certbot validate the wrong Apache virtual host?
Common causes are duplicate ServerName or ServerAlias entries, default-vhost ordering, an IPv6 AAAA record pointing elsewhere, or a proxy answering before Apache. Use apachectl -S and inspect both A and AAAA DNS records.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Is a 404 from a manual challenge test always a failure?
No. A 404 for a nonexistent test file is expected. It becomes a problem when Certbot’s real token is written to a different webroot or when the challenge path is blocked by authentication, rewrites, proxying, or permissions.
How do I renew certificates for all virtual hosts?
Run certbot renew. Certbot evaluates every managed certificate and renews only those inside its readiness window. Run certbot renew --dry-run after routing, DNS, firewall, or webroot changes.
What is the renewal threshold?
As of Certbot 4.0.0, renewal is considered ready when less than one third of the certificate lifetime remains. For certificates lasting 10 days or less, the threshold is one half of the lifetime.
What if Apache keeps serving the old certificate after renewal?
Reload Apache after Certbot updates the files. Validate first with apachectl configtest; if automatic reloading is not configured, use a tested deploy hook such as systemctl reload apache2.
Free tools Windows power users keep installed
One-click scans. No signup required.
Can I use HTTP-01 when port 80 is unavailable?
No. Use DNS-01 with a supported DNS automation method, or evaluate Apache mod_md. DNS-01 proves control with a TXT record and avoids inbound HTTP reachability, but Apache still needs the resulting certificate configured.
The Bottom Line
For multiple Apache virtual hosts, map every public name to its real port-80 vhost before issuing anything. Use one SAN certificate for tightly coupled names, separate certificates for independent sites, and group -w options carefully when roots differ. Wire certificates through the stable /etc/letsencrypt/live/ paths, verify vhost selection with apachectl -S, and make certbot renew --dry-run part of every routing or configuration change. Finally, ensure Apache reloads after renewal and choose a single lifecycle owner—Certbot or mod_md—for each certificate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
