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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain

I ran this command: I installed this all on digital ocean, I have the cert in my a records, and when I went to the site to test my SSSL it gave me an A rating still getting the security issue

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, web host is network solutions, my controller is on Digital ocean

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

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):

Hi @john-bailey

checking this subdomain there is all good -

The certificate is valid
expires in 90 days - 1 entry

and used, a Grade B is very good.

Is there an error with that domain? Perhaps only an old cache, share a screenshot.

Your main domain - https doesn't work -

But that's expected, there is no certificate:

Issuer not before not after Domain names LE-Duplicate next LE
Let's Encrypt Authority X3 2019-08-30 2019-11-28 - 1 entries duplicate nr. 1
Amazon 2019-07-12 2020-08-12, - 2 entries
Amazon 2018-08-09 2019-09-09, - 2 entries

so no SSL connection is possible.

The error:

Error creating a TLS-Connection: IANA TLS Alert No. 80, internal_error. An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue. SSL_ERROR_INTERNAL_ERROR_ALERT (Mozilla) / ERR_SSL_PROTOCOL_ERROR (Chrome)

So first step: Create a certificate with your main domain + www

I am stupid, sorry, can you let me know exactly what this means?

Where do you see that error message?


Your subdomain doesn’t have a certificate error.

And your main domain doesn’t have a https version with a wrong certificate. There is no https, not with a correct, not with a wrong certificate (self signed, expired, wrong domain name).

So both domains don’t show that error.

ok so i created an A record with my actual website hosting company to point to my hosted Digital ocean droplet, with a unifi controller on it. so I followed the instructions from the guys at crosstalk to get everything up and running, even my ssl certificate. i ran all the commands on my ubuntu server
this is the site I went to after as instructed
does any of this make sense yet?

here are the instructions I was following
Install Certbot:

sudo add-apt-repository ppa:certbot/certbot

Press ENTER to continue when prompted.

sudo apt-get update sudo apt-get install python-certbot-apache -y

Now Certbot is installed, so the next step is to generate our SSL certificate.

sudo certbot --apache -d

Substitute your own FQDN instead of When prompted, enter in an email address for use with the SSL cert. Then press A to Agree when prompted followed by Y or N to share your email address with the Electronic Frontier Foundation (I said N). Next you will be asked if you want to redirect all HTTP traffic to HTTPS – choose option 2. Your Let’s Encrypt certificate has now been installed.

Next, we need to import that SSL certificate into UniFi – or in other words, we have to tell UniFi to use the Let’s Encrypt certificate.

A developer named Steve Jenkins created a really great script that automates the rest of the process, making it super easy. So, thanks to Steve, and let’s download his script and modify a few settings.

sudo wget -O /usr/local/bin/ sudo chmod +x /usr/local/bin/

Next, edit the /usr/local/bin/ file that we imported:

sudo nano -w /usr/local/bin/

Find the line that says ‘UNIFI_HOSTNAME’ and change it to your own FQDN:

Next, since we are on a Ubuntu Vultr server instead of a flavor of RedHat (which the script was based on), we need to comment out the RedHat stuff and uncomment the Debian/Ubuntu stuff:

Uncomment following three lines for Fedora/RedHat/CentOS #UNIFI_DIR=/opt/UniFi #JAVA_DIR={UNIFI_DIR} #KEYSTORE={UNIFI_DIR}/data/keystore # Uncomment following three lines for Debian/Ubuntu UNIFI_DIR=/var/lib/unifi JAVA_DIR=/usr/lib/unifi KEYSTORE=${UNIFI_DIR}/keystore

Next, enable Lets Encrypt mode (change LE_MODE=no to LE_MODE=yes):

LE_MODE=yes LE_LIVE_DIR=/etc/letsencrypt/live

Save and exit nano by doing CTRL+X followed by Y.

Finally, run the script!

sudo /usr/local/bin/

If you now close your browser and then re-open it to https://[your UniFi FQDN]:8443, you should no longer have the security warnings, and you will have a valid HTTPS certificate installed. And no more pesky security warnings.

Let’s test this certificate further by running it against an SSL Server Test from Open the following URL in your browser:

Substitute my FQDN for your own. This test takes a couple of minutes to run, but when complete, it should verify that everything is A-OK.

Where is there an error?

That's a Grade A, that's good.

this is my digital ocean hosted unifi controller

see this is where I am running into a problem I dont know why it is doing this

this is the a record I created does it look right?

If you use the ip address, the certificate is always wrong.


that works with your certificate.

so wait dont we have to point to the ip address of the server hosting my controller?

so do I need to do anything different in the set up in ssh or do I leave it alone?

That's already done -

Host T IP-Address is auth. ∑ Queries ∑ Timeout A North Bergen/New Jersey/United States (US) - DigitalOcean, LLC Hostname: yes 1 0
AAAA yes Name Error yes 1 0

The check is 45 minutes old - and it's the same ip address you have shared.

sorry for being stupiud, how much do you know about unifi controlelr and pre authenitaction in the guest portal? meaning I am trying to put the correct url into the pre auth and it throws up not allowing me so it needs a ip address or proper domain name and not the :8443/
it has to do with redirect urls and https, getting errors,
or if I put in that should cover it?

in my a record on my provider should we add the 8443 to the ip addrss maybe?

got it all figure out thank you so so much!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.