HTTPS Certificate Renewal and Mixed Content Issues Affecting My Real-Time Morse Code Website Using Let’s Encrypt

Help
1

I run a fairly interactive Morse Code translator website that converts text into Morse code and decodes Morse back into readable text in real time using JavaScript. The site also includes audio playback for dots and dashes, dynamic UI updates, and optional sharing features. Recently, I migrated the site to HTTPS using Let's Encrypt certificates because I wanted modern browser compatibility and better security for users. While the SSL setup initially worked correctly, I’ve started running into recurring certificate, renewal, and mixed-content issues that are affecting the reliability of the website.

One of the biggest problems is automatic certificate renewal. The site is hosted on a lightweight VPS with Nginx, and I’m using Certbot for certificate management. Renewal appears to work sometimes, but on a few occasions the certificate expired unexpectedly and users began seeing browser security warnings before I noticed the issue. Since the Morse Code translator relies heavily on browser APIs like Web Audio and clipboard access, some features stop functioning properly when the browser marks the connection as insecure. I’m trying to understand the most reliable way to monitor and automate certificate renewal without risking downtime.

Another issue involves mixed-content warnings related to older assets and external resources. While most of the website now loads over HTTPS, a few JavaScript libraries, audio resources, or image assets were originally referenced using HTTP URLs. Modern browsers block some of these requests entirely, which occasionally causes parts of the translator interface or Morse code audio playback to fail. I’ve updated many of the links manually, but I’m wondering if there are recommended strategies or tools for identifying and preventing mixed-content issues more systematically.

I’m also seeing inconsistent HTTPS behavior across subdomains and staging environments. The main Morse Code website works correctly over HTTPS, but staging versions or alternate subdomains sometimes produce certificate mismatch errors or redirect loops after renewal attempts. Because I frequently test updates to the translation logic and frontend scripts before deployment, I need a setup that supports multiple environments cleanly. I’d appreciate guidance on best practices for managing Let’s Encrypt certificates across development, staging, and production domains.

Another area of confusion is browser trust and caching behavior after certificate updates. There have been situations where the certificate appeared valid on one device but still produced warnings on another due to cached SSL state or DNS propagation timing. Since the site’s users access it from many mobile and desktop browsers, troubleshooting these inconsistencies has been difficult. I’m interested in learning whether there are recommended diagnostic tools or workflows for verifying certificate health and propagation after renewals.

Finally, I’d really appreciate advice from the Let’s Encrypt community on the ideal long-term setup for a small but interactive web application like this. The Morse Code translator itself is lightweight, but because it depends on secure browser APIs and real-time functionality, HTTPS reliability is extremely important. I’d like recommendations on certificate automation, monitoring, multi-subdomain management, and preventing mixed-content problems so the site remains secure and stable without constant manual intervention. Sorry for long post

2

Hello @glenphillips, welcome to the Let's Encrypt community. :slightly_smiling_face:

When you opened this thread in the Help section, you should have been provided with a questionnaire. Maybe you didn't get it somehow (which is weird), or you've decided to delete it. In any case, all the answers to this questionnaire are required:

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

Thank you for assisting us in helping YOU!

3

@glenphillips There is no single recommendation for all your topics. Your needs and requirements dictate the ideal solutions. It is not practical for us to lay out every possible solution. There are numerous sources to help with overall design and management of apps. Certs and HTTPS may be new to you but this has been common practice for a long time.

We will be happy to help you with the specific issues related to getting and managing certs. Sometimes some of us go beyond that but that's the area we focus on.

We'll need the info from the form @Bruce5051 re-posted to begin working on the renewal failures.

As for monitoring, you can build your own health check or rely on a third-party monitoring system. Examples: Monitoring Service Options - Let's Encrypt

That's an application design / migration issue. Not sure how we could help with that. Seems you are aware of what it is and what needs doing.

The certificate needs to include the domain name used in a URL. Otherwise the clients will fail the https connection. A wildcard cert can sometimes help when using a wide variety of domain names. We could guide more specifically once we know that info on the form.

Yes, browsers sometimes cache those things. You should use a monitoring tool that is not subject to caching. Or, as mentioned, develop one of your own. The curl and openssl tools are often helpful. Many languages have API for making and interpreting results of HTTPS (TLS) connections.

Once we know more about your system, like the o/s and version, we could give more specific examples.

4

I think you should first set up an external monitoring system to detect the remaining validity period of the certificate, so that even if the Certbot automatic renewal fails, you can still receive an alarm before the expiration for manual intervention.

5

You may use the HTTP header: Content-Security-Policy: upgrade-insecure-requests directive - HTTP | MDN

It will instruct browsers to treat all http:// URLs as if they were https://.

If the target hostname does not support HTTPS, these requests will fail, but given browsers already block these, it should be no additional harm.

6

Thanks, that’s a really useful suggestion.

Using the Content-Security-Policy: upgrade-insecure-requests header sounds like a good safety net while I continue cleaning up older asset references. Since browsers are already blocking many insecure requests, automatically upgrading remaining http:// resources to HTTPS could help reduce breakage in the short term, especially for legacy scripts or audio assets I may have missed during migration.

I’ll test it carefully across the translator’s audio and dynamic UI components to make sure none of the third-party resources fail unexpectedly if they don’t support HTTPS properly. It also seems like a cleaner approach than trying to manually catch every mixed-content issue one by one. Appreciate the recommendation this gives me a more systematic way to harden the HTTPS setup while I improve the renewal and subdomain management side separately.