Certificate renewal

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: aioradar.com

I ran this command:
We have multiple sites. So, I ran the following command:
Sudo certbot renew --dryrun

I got an email notification that the certificate was renewed for most of the sites except for two, for which I know the reason. In this list of successful additions, aioradar.com was also one of them. However, I still get notifications that the site requires renewal.

It produced this output:
Successfully installed

/etc/letsencrypt/live/aioradar.com/full chain.pem (success)

My web server is (include version):

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

My hosting provider, if applicable, is:
Own server

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):
Usually, yes, but now, we are working on an upgrade and updated the certificates command line.

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

2 Likes

You ran a dry run, which is for testing your configuration. It will generate false certificates.

If your certificate was successfully renewed, it would appear here:
https://crt.sh/?q=aioradar.com

1 Like

Thanks for getting back to me.

I think that this domain is not the one having the issue. It is another. This one is on Nginx server. I followed the certbot renewal process and also ran the shell that was created last time for this purpose, but it is throwing an error.

The domain is: aioexplorer.com

Error: Challenge Failed
Type: Unauthorized

Nothing has changed much for this server between now and when we last renewed/installed.

2 Likes

Hi @skidambi75,

If you run sudo certbot renew or sudo certbot renew --dry-run, you should get much more output than just

Error: Challenge Failed
Type: Unauthorized

Could we see the full output from the Certbot command?

2 Likes

@schoen: thanks. Here are the complete details presenting commands tried and errors.

Commands tried and errors/messages:

Internal shell script
./inst*

This script will:

  • Need a working DNS record pointing to this machine(for domain aioexplorer.com)
  • Download certbot from https://dl.eff.org to /usr/local/sbin
  • Install additional dependencies in order to request Let’s Encrypt certificate
  • If running with jetty serving web content, will stop Jitsi Videobridge
  • Configure and reload nginx or apache2, whichever is used
  • Configure the coturn server to use Let’s Encrypt certificate and add required deploy hooks
  • Add command in weekly cron job to renew certificates regularly

You need to agree to the ACME server’s Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)
by providing an email address for important account notifications
Enter your email and press [ENTER]:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate


Certificate not yet due for renewal; no action taken.


Configuring nginx

sudo certbot certonly --force-renewal -d www.aioexplorer.com,aioexplorer.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?


1: Nginx Web Server plugin (nginx)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)


Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 1
Plugins selected: Authenticator nginx, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.aioexplorer.com
nginx: [emerg] “server_names_hash_bucket_size” directive is duplicate in /etc/nginx/sites-enabled/aioexplorer.com.conf:1
Cleaning up challenges
nginx restart failed:
b’’
b’’

certbot certonly --webroot -w /usr/share/jitsi-meet -d *.aioexplorer.com -d aioexplorer.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None


You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/aioexplorer.com.conf)

It contains these names: aioexplorer.com

You requested these names for the new certificate: *.aioexplorer.com,
aioexplorer.com.

Do you want to expand and replace this existing certificate with the new
certificate?


(E)xpand/©ancel: E
Renewing an existing certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for www.aioexplorer.com
Using the webroot path /usr/share/jitsi-meet for all unmatched domains.
Waiting for verification…
Challenge failed for domain www.aioexplorer.com
http-01 challenge for www.aioexplorer.com
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:

2 Likes

it looks like jitsi makes some customization to nginx’s config that doesn’t go down to well with certbot.

I suggest:

mkdir -p /var/www/certbot

then create a /etc/nginx/sites-available/certbot file:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  location /.well-known/acme-challenge/ {
    root /var/www/certbot;
  }
  # If you want an http -> https redirect, put it here
}

and then

ln -s /etc/nginx/sites-available/certbot /etc/nginx/sites-enabled

and

service nginx configtest

this is when any problem will surface, if it needs to complain it will (about default_server, mainly). correct it before going on.

when it does not complain anymore,

service nginx reload

and

certbot renew --webroot -w /var/www/certbot \
              --deploy-hook "service nginx reload"
2 Likes

@9peppe:

Thanks for your suggestion. I followed the suggested instructions, but it appears to be conflicting with the existing conf file.

See the output below -
ug 11 19:01:17 jitsi systemd[1]: Starting A high performance web server and a reverse proxy server…
Aug 11 19:01:17 jitsi nginx[8856]: nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites-enabled/defa>
Aug 11 19:01:17 jitsi nginx[8856]: nginx: configuration file /etc/nginx/nginx.conf test failed
Aug 11 19:01:17 jitsi systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Aug 11 19:01:17 jitsi systemd[1]: nginx.service: Failed with result ‘exit-code’.
Aug 11 19:01:17 jitsi systemd[1]: Failed to start A high performance web server and a reverse proxy server.
Aug 11 19:05:57 jitsi systemd[1]: nginx.service: Unit cannot be reloaded because it is inactive.

As soon as I removed the newly created file, the server was back and fully functional.

===========================================================
This is what is inside the current conf file -
server_names_hash_bucket_size 128;

server {
listen 80;
listen [::]:80;
server_name aioexplorer.com www.aioexplorer.com;

location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root         /usr/share/jitsi-meet;
}
location = /.well-known/acme-challenge/ {
   return 404;
}
location / {
   return 301 https://$host$request_uri;
}

}

2 Likes

It looks like aioexplorer.com and www.aioexplorer.com use two separate webroots.

This usually means some kind of webserver misconfiguration. Not in your case: dns misconfiguration it is:

% dig +short a aioexplorer.com
178.79.176.219
162.255.119.172

% dig +short a www.aioexplorer.com
178.79.176.219

% for ip in $(dig +short a aioexplorer.com); do echo $ip; curl -IL $ip; curl -IL --resolve aioexplorer.com:443:$ip https://aioexplorer.com; done
178.79.176.219
HTTP/1.1 200 OK
Date: Tue, 11 Aug 2020 20:10:08 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Wed, 20 May 2020 16:11:18 GMT
ETag: "ebb-5a616a568bcdb"
Accept-Ranges: bytes
Content-Length: 3771
Vary: Accept-Encoding
Content-Type: text/html

HTTP/2 200 
server: nginx/1.17.10 (Ubuntu)
date: Tue, 11 Aug 2020 20:10:09 GMT
content-type: text/html
vary: Accept-Encoding
strict-transport-security: max-age=31536000

162.255.119.172
HTTP/1.1 204 No Content
Server: nginx
Date: Tue, 11 Aug 2020 20:10:09 GMT
Connection: keep-alive
X-Served-By: Namecheap URL Forward

curl: (7) Failed to connect to aioexplorer.com port 443: Connessione rifiutata

% for ip in $(dig +short a www.aioexplorer.com); do echo $ip; curl -IL $ip; curl -IL --resolve www.aioexplorer.com:443:$ip https://www.aioexplorer.com; done
178.79.176.219
HTTP/1.1 200 OK
Date: Tue, 11 Aug 2020 20:10:23 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Wed, 20 May 2020 16:11:18 GMT
ETag: "ebb-5a616a568bcdb"
Accept-Ranges: bytes
Content-Length: 3771
Vary: Accept-Encoding
Content-Type: text/html

HTTP/2 200 
server: nginx/1.17.10 (Ubuntu)
date: Tue, 11 Aug 2020 20:10:24 GMT
content-type: text/html
vary: Accept-Encoding
strict-transport-security: max-age=31536000



And it also looks like you have Apache on port 80 and nginx on port 443… if you didn’t do it on purpose you have a problem. If you did do it on purpose, you have to do the challenges through apache, not nginx.

3 Likes

Thanks for bringing this to my attention. I also confirmed the same using nslookup and identified an extra url redirect record causing it. That has been taken care of now. Would this resolve the issue?

There is a cron shell script that says the domain is not yet available for renewal, which is right as there is still 10 days or so left. In that case, if I decide to renew manually, what would be the suggested way?

2 Likes

It was necessary to resolve it, but I don’t think it will be sufficient.

That’s not right, it should renew automatically at 30 days left, not 10. It’s probably referring to your non-www domain, which has a 79-day certificate. https://tools.letsdebug.net/cert-search?m=domain&q=%20aioexplorer.com&d=2160

About the whole apache and nginx thing: what can you tell me about it?

You could try with a certbot renew --apache --dry-run and see if it works…

2 Likes

@9peppe:

I have done this renewal process many times before and should not be this complicated. Anyways, I decided to retrace the steps that I have done until now and thought of sharing.

  1. This is nginx server and not an apache server. I am confident of it. However, as this community does not know the complete story, I am sharing the same here. Just ran a set of basic server commands to confirm that.

########:~$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-08-12 10:56:24 UTC; 6min ago
Docs: man:nginx(8)
Process: 216 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 258 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 739 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)
Main PID: 283 (nginx)
Tasks: 5 (limit: 65000)
Memory: 21.2M
CGroup: /system.slice/nginx.service
├─283 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─741 nginx: worker process
├─742 nginx: worker process
├─743 nginx: worker process
└─744 nginx: worker process

Warning: some journal files were not opened due to insufficient permissions.

#######:~$ systemctl status apache2.service
Unit apache2.service could not be found.

  1. As mentioned, both the www.aioexplorer.com and aioexplorer.com ssls have been functional for some time now, even with the redirect URL record that was showing two different ip addresses.

  1. Commands tried:
    a.Ran the following script, which led to the following error:
    #!/bin/bash
    /usr/bin/certbot renew >> /var/log/le-renew.log
    service nginx reload

error:
Challenge failed for domain www.aioexplorer.com
http-01 challenge for www.aioexplorer.com
Cleaning up challenges
Attempting to renew cert (www.aioexplorer.com) from /etc/letsencrypt/renewal/www.aioexplorer.com.conf produced an unexpected error: Some challenges have failed… Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/www.aioexplorer.com/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

b. root@j######### ./install* (Cron script that is usually provided for renewing SSL scripts).

This script will:

  • Need a working DNS record pointing to this machine(for domain aioexplorer.com)
  • Download certbot-auto from https://dl.eff.org to /usr/local/sbin
  • Install additional dependencies in order to request Let’s Encrypt certificate
  • If running with jetty serving web content, will stop Jitsi Videobridge
  • Configure and reload nginx or apache2, whichever is used
  • Configure the coturn server to use Let’s Encrypt certificate and add required deploy hooks
  • Add command in weekly cron job to renew certificates regularly

You need to agree to the ACME server’s Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)
by providing an email address for important account notifications
Enter your email and press [ENTER]: ###########
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate


Certificate not yet due for renewal; no action taken.


Configuring nginx

c. Went through the sequence from scratch given on the cerbot site and reinstalled/updated all related apt files and tried to renew the certificate.

Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Get:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease [111 kB]
Get:3 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease [98.3 kB]
Hit:5 https://download.jitsi.org stable/ InRelease
Get:6 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [322 kB]
Get:7 http://archive.ubuntu.com/ubuntu focal-updates/main Translation-en [121 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 c-n-f Metadata [8252 B]
Get:9 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages [154 kB]
Get:10 http://archive.ubuntu.com/ubuntu focal-updates/universe Translation-en [76.6 kB]
Get:11 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 c-n-f Metadata [5220 B]
Fetched 1004 kB in 2s (520 kB/s)
Reading package lists… Done
Reading package lists… Done
Building dependency tree
Reading state information… Done
software-properties-common is already the newest version (0.98.9.1).
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
‘universe’ distribution component is already enabled for all sources.
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:5 https://download.jitsi.org stable/ InRelease
Reading package lists… Done
Reading package lists… Done
Building dependency tree
Reading state information… Done
certbot is already the newest version (0.40.0-1).
python3-certbot-nginx is already the newest version (0.40.0-0ubuntu0.1).
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

error:
root@jitsi:~# sudo certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/aioexplorer.com.conf


Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for aioexplorer.com
Using the webroot path /usr/share/jitsi-meet for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Dry run: skipping deploy hook command: /etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh
Skipping deploy-hook ‘/etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh’ as it was already run.


new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/aioexplorer.com/fullchain.pem



Processing /etc/letsencrypt/renewal/www.aioexplorer.com.conf


Cert is due for renewal, auto-renewing…
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for www.aioexplorer.com
http-01 challenge for aioexplorer.com
Using the webroot path /usr/share/jitsi-meet for all unmatched domains.
Waiting for verification…
Challenge failed for domain www.aioexplorer.com
http-01 challenge for www.aioexplorer.com
Cleaning up challenges
Attempting to renew cert (www.aioexplorer.com) from /etc/letsencrypt/renewal/www.aioexplorer.com.conf produced an unexpected error: Some challenges have failed… Skipping.
The following certs could not be renewed:
/etc/letsencrypt/live/www.aioexplorer.com/fullchain.pem (failure)


** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates below have not been saved.)

The following certs were successfully renewed:
/etc/letsencrypt/live/aioexplorer.com/fullchain.pem (success)

The following certs could not be renewed:
/etc/letsencrypt/live/www.aioexplorer.com/fullchain.pem (failure)
** DRY RUN: simulating ‘certbot renew’ close to cert expiry
** (The test certificates above have not been saved.)


1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: www.aioexplorer.com
    Type: unauthorized
    Detail: Invalid response from
    http://www.aioexplorer.com/.well-known/acme-challenge/#######
    [178.79.176.219]: “\n\n404 Not
    Found\n\n

    Not Found

    \n<p”

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.
    ============================================================

d. certbot certonly --webroot -w /usr/share/jitsi-meet -d *.aioexplorer.com -d aioexplorer.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None


You have an existing certificate that contains a portion of the domains you
requested (ref: /etc/letsencrypt/renewal/aioexplorer.com.conf)

It contains these names: aioexplorer.com

You requested these names for the new certificate: *.aioexplorer.com,
aioexplorer.com.

Do you want to expand and replace this existing certificate with the new
certificate?


(E)xpand/©ancel: E
Renewing an existing certificate
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

=============================================================

I also asked the question what system change was done, which could result in authenticator or other errors, and we did update the server to 20.0.4. So, I went through the sequence to update the python environment apt files etc to accommodate for the update.

As per a Jitsi forum, this was also brought up, which confirmed my thought process.

I also followed their instructions and modified the installation shell script accordingly. The output presented above was after the change in the script. Before the change, it was not resulting in the error, but was pointing out the unavailability of Python scripts.

===============================================================

This is where I am. Majority of these commands were tried prior to coming to this forum to identify a working solution.

Any further input to resolve this issue would be appreciated.

2 Likes

Forgot to include this one as well. I also tried this one without much success.

I also initiated a concurrent thread over at Jitsi to address this issue as well.

2 Likes

Out of curiosity, did you change your configuration for the renewal certificate to be a wildcard *. where previously you certified your base domain and www. separately?

I ask because:

@schoen
Didn’t you tell me something the other day about how certbot would not performed mixed (http and dns) challenges without specifying both in --preferred-challenges. I believe this mattered when using a wildcard cert where previously there was no wildcard.

@skidambi75
I believe you’re getting these failures because you’re trying to use http challenges with a wildcard, which requires dns challenge. Since you didn’t specify --preferred-challenge, it will try to use dns challenges for BOTH domains.

1 Like

Let me check the historical records and get back to you. I believe that I tried without the wild card. But, not certain.

2 Likes

I noticed that you tried to expand (overlap the www) with the wildcard here. Your webroot will be irrelevant since a dns verification is required for wildcard.

My honest suggestion is that you do a “–manual --preferred-challenges dns -d aioexplorer.com -d *.aioexplorer.com” certification, manually add the DNS TXT records, and get and install a correct certificate just to get your ducks in order. Then try updating your process accordingly. That way you don’t have multiple certs interfering with the process.

2 Likes

I just checked the records, and we have both listed. Not sure why. It has been a while. Usually, those did not appear to impact in the past.

I tried again three variants and the good news is that this one worked - @ (or without the hostname), which appears to align with your suggestion that it could be connected to wild card expansion. Thanks @freessltools.com

============================================================

Without the hostname,
IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    ############/aioexplorer.com/fullchain.pem
    Your key file has been saved at:
    ############/aioexplorer.com/privkey.pem
    Your cert will expire on 2020-11-10. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot
    again. To non-interactively renew all of your certificates, run
    “certbot renew”

Without the wildcard, only www & @
Challenge failed for domain www.aioexplorer.com

With the wildcard, * & @
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

===============================================================

If you don’t mind, can you be explicit about the last part in your previous message? This would help me to add the wild card expansion to this certificate.

Blockquote

*My honest suggestion is that you do a “–manual --preferred-challenges dns -d aioexplorer.com -d .aioexplorer.com” certification, manually add the DNS TXT records, and get and install a correct certificate just to get your ducks in order. Then try updating your process accordingly. That way you don’t have multiple certs interfering with the process.

2 Likes

Glad it worked! :grinning:

So, if I’m understanding correctly, it looks like you previously got separate certificates for aioexplorer.com and www.aioexplorer.com, which will cause you to have different renewals. Combining them (and expanding to *.aioexplorer.com) is wise as it prevents a lot of confusion (and gives you more coverage than just www.). Trouble is that you can’t use file-based challenges over http to do it. I suppose you could partially for the non-www, but why bother if you must use dns for *. anyhow.

My suggestion above was just to use a manual intervention process (which ignores the renewal dates) to get a correct certificate installed so that you would have the exact domains (aioexplorer.com and *.aioexplorer.com) you want in your cert. It was just to get you a baseline. :slightly_smiling_face:

1 Like

The irony here is that all the previous renewal failures were for www.aioexplorer.com. When you use the wildcard, you replace the broken http challenge with a dns challenge that requires dns txt records (which I don’t believe you have a hook to create/destroy automatically). That’s why I suggested the manual route. If you don’t mind, try the following and tell me what you get:

certbot certonly --manual --preferred-challenges dns -d *.aioexplorer.com -d aioexplorer.com

2 Likes

Yes, I was just working on it, when you had shared this message. I had to sign into the registrar to add the record. Anyways, it is all done and I have added the wild card entry. This should help for the future. Thanks again for your timely assistance. It took a while to resolve, but that certainly helped to clean up my understanding on this certification process, and also to go over the Nginx server settings after a while.

2 Likes

Keep in mind that certonly does not install the certificate. It only gets you the certificate. I wanted to make sure we got that far first. :slightly_smiling_face: Now you need to (cross your fingers and) install the new certificate. The process I had you go through does not solve your renewal configuration problems, but those can be resolved after you get a functional certificate for the correct domain combination installed.

Try:
certbot install -d aioexplorer.com -d *.aioexplorer.com

While I am hopeful, I fear that this might come to haunt us:

Currently:

Is there a reason you’re not permanently redirecting aioexplorer.com to www.aioexplorer.com (or vice versa)? It’s really bad for your search rankings to have non-authoritative duplication like this. Having a single canonical address is usually preferable.

2 Likes