Letsencrypt breaks my tracking script?

So, I have a problem …

I have a tracking script installed on a digital ocean server … it’s called CPVlab. It enables me to track clicks and gives me statistics on the click. What it does is catch info on a user and their behavior and it can rotate landing pages for split testing those landing pages. This is all done through internal redirects on the domain the script is installed on.

Let’s say it’s installed on : tracker.com

Another feature of the script is : I can enter an A record in the DNS I use and call it someothername.com and point it to the IP adres of the tracker.com.

This way, one can use different domains (tracking domains) in order to not have the main installation domain visible. This helps with customizing the look of different marketing campaigns (you don’t want them all to look like : tracker.com/? querystuff)…

So here’s the problem :
It all used to work fine without https:// … But after installing letsencrypt (through an easyengine command for bothe tracker.com as well as tracking domains) the explained feature doesn’t work anymore.

When using **http://**someothername.com as an A record pointing to tracker.com, the server shows me a 404 not found status. And when I use a **https://**someothername.com as an A record pointing to the script, it tells me the connection is not secure. This while both domains have https certificates and they work if I put them in the browser direct. (it will show https).

However when I don’t use this tracking domain feature and just use the plain https://tracker.com domain, it works perfectly.

Maybe this question is a bit far out, but does anyone have an idea if this is realted to letsencrypt ? I added the certificates through EE a few months ago, and I know EE uses certbot. However I am thinking that this problem may have something to do with letsencrypt not supporting wildcards at the time of install. Maybe this tracking script is designed in some way that the main domain uses the tracking domains as some sort of sub domain ?

Anyone have an idea about this ? I am definately STUCK here…



This might have something with your scripts intergration.

As your https is set up and working, there are nothing we can do.

Thank you

You mean that the script isn’t built to handle LE ssl ? If so, then I’m wondering why it.still works when only using the domain that the script was installed on …

Also … is there a way to completely undo the LE ssl implememtation ? Revoke certificate and clean the nginx config for example ?


I Mean Maybe the Nginx SSL vHost is setup incorrectly.

For Full SSL Implementation, please check on your software provider’s documentation.

Thank you

I see … can you explain wich direction I should look ?


Try looking at files in /etc/nginx/sites-enabled/ and check if the 443 vHost is listed correctly.


Check your software provider’s wiki / docs for more information.

Thank you

Ofcourse … There are basically two domains that are playing a role here … the maindomain (where the script is installed) and the domain that is used in order to mask the main domain (tracking domain). The main domain is secured with LE and the tracking domain I’ve tried both secured with LE and unsecured…

Maindomain : etc/nginx/sites-enabled/maindomain.com (where the script is installed)

server {

    server_name maindomain.com   www.maindomain.com;

    access_log /var/log/nginx/maindomain.com.access.log rt_cache;
    error_log /var/log/nginx/maindomain.com.error.log;

    root /var/www/maindomain.com/htdocs;

    index index.php index.html index.htm;

    include common/php.conf;

    include common/locations.conf;
    include /var/www/maindomain.com/conf/nginx/*.conf;

included file ( /var/www/maindomain.com/conf/nginx/*.conf;) (this is an ssl.conf file)

ssl on;
ssl_certificate     /etc/letsencrypt/live/maindomain.com/fullchain.pem;
ssl_certificate_key     /etc/letsencrypt/live/maindomain.com/privkey.pem;

Force ssl (etc/nginx/conf.d/force-ssl-maindomain.com.conf

server {
        listen 80;
        server_name www.maindomain.com maindomain.com;
        return 301 https://maindomain.com$request_uri;

So, this works if I keep it all on the maindomain.com … but once I add a tracking domain into the mix, I get the error messages. Personally, I don’t see anything weird with the setup, but it might just be the way the script deals with it ?

Just to clarify: did you just get a certificate for the main domain, or did you also get one for the tracking domain (or one that covers both names)?

When you enable the tracking domain does that modify your nginx configuration or do you modify it yourself? If so what does the modified configuration look like?

I have a certificate for each domain … The config shown above is the one for the main domain (the domain where the script is installed). EasyEngine just adds the lines that are relevant to SSL.

When adding a tracking domain, nothing is changed in the nginx files. The name of the tracking domain is basically inserted as a masked main domain by use of PHP … How they do this I don’t know, but there is no change to the nginx files, that I am sure of.

I know this because, when I use a tracking domain with LE ssl on it, and I use it as a tracking domain, it tells me that the connection is insecure. While seeing the name of the tracking domain in the address bar, and checking the certificate, it says that it’s insecure because the certificate is issued to the MAIN DOMAIN …

So the script is actually putting the tracking domain name onto the main domain, and LE certificates seem to then become ‘mixed’ … (I am just using my logic here, so forgive me if I am wrong here…)

Also : it should actually make not difference if the tracking domain as an SSL. When I used to use this feature with a commercial certificate, I was just registering domains purely to use as a mask for the MAIN DOMAIN, immediately pointing it to the MAIN DOMAIN where the script is installed. I am still inclined to think the script doesn’t know how to handle LE ssl correctly … can this be the case ?

I can also find some errors in the log … looks like there’s a handshake failure.

2018/04/05 22:08:18 [crit] 1732#0: *3199 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:ssl3_read_bytes:ccs received early) while SSL handshaking, client:, server:
2018/04/18 07:56:50 [crit] 1742#0: *571 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:ssl3_read_bytes:ccs received early) while SSL handshaking, client:, server:
2018/04/18 07:56:50 [crit] 1742#0: *572 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:ssl3_read_bytes:ccs received early) while SSL handshaking, client:, server:
2018/04/18 07:59:30 [crit] 1742#0: *793 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:ssl3_read_bytes:ccs received early) while SSL handshaking, client:, server:
2018/04/18 07:59:30 [crit] 1742#0: *794 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:ssl3_read_bytes:ccs received early) while SSL handshaking, client:, server:
2018/04/19 04:48:43 [crit] 6772#0: *557 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:ssl3_read_bytes:ccs received early) while SSL handshaking, client:, server:
2018/04/19 04:48:44 [crit] 6772#0: *558 SSL_do_handshake() failed (SSL: error:14094085:SSL routines:ssl3_read_bytes:ccs received early) while SSL handshaking, client:, server:

The errors above are only when using the tracking domain feature. Otherwise, SSL on the main domain works normally. (yes weird)

I'm still a little confused by this - in what sense does the tracking domain have "LE ssl on it"? Did you obtain a certificate for the tracking domain and install it somewhere?

When a browser connects via HTTPS to the tracking domain it first connects to port 443 of whatever server you're running there (nginx it seems), and tells it "I'd like to connect securely to trackingdomain.com please". The web server then checks if it knows about that domain - in the case of nginx, does a server block exist for it - and if so sends the certificate configured for that server block. Otherwise it uses a default (or rejects the connection, depending on how it's configured). The browser then verifies that the certificate the server sent is valid for the domain it requested.

What this means is that if your tracking domain is pointed at your nginx server, then nginx needs to serve a certificate that's valid for the tracking domain when a browser connects to that domain, which means that whatever server block is being chosen must be configured to point to such a certificate. If that's not the case (which it sounds like it's not), then you'll get a security warning.

I'm not sure how to set that up with EE though. You could do it directly with certbot - see the docs for adding additional names to a certificate - but I don't know if that would conflict with EE's automation.

I don't know how it would have worked before with a commercial cert as those work exactly the same way. Perhaps it was connecting over HTTP rather than HTTPS? If so maybe adding the cert somehow broke your HTTP configuration? I wouldn't recommend using HTTP as a solution though because (1) HTTP scripts don't work on HTTPS pages and (2) tracking data really ought to be secure anyway.

The errors in your logs look like they may have been generated by the SSL Labs test - did you run that test during those times? If so, the errors are expected and irrelevant.

Yes I’ve ran a labs test and it gave me a B … but that aside. I think I am done with this problem. I think I am going to manually install a comodo SSL to see if that make a difference …



So guess what … I was able to solve it by adding a wild card *.com in the server_name setting of nginx and forcing that to https://maindomain$request_uri;

This way the A record points to the main server and the server does it’s job …

Now I don’t know if this is the intended way, but I sure don’t know any other …

Any opinions ?

Do you mean that you added the wildcard server_name in the HTTP server block?

I guess that means you’re loading the tracking script by its HTTP URL?

That might work, to some extent. If the tracking script depends on the domain name to identify the campaign, the redirect might break that. It won’t work at all if the domain where you’re using the script uses HTTPS, because browsers will block the HTTP request before it gets a chance to redirect to HTTPS.

I don’t know how EE does things but I suspect you might get better results by explicitly listing all your tracking domains in the server_name and re-running whatever command it provides to obtain a cert. Ideally you want to get either a certificate for each domain, or a single certificate covering all the domains. That way you can just load the script over HTTPS rather than depending on redirects.

Actually alsmost … what’s happening is this:

  1. I am adding a A record for a tracking domain that points to the main domain (tracker server). This main domain (tracker) has a SSL certificate.

  2. I am letting nginx force the tracking domain to the main domain like so :

    server {
    listen 80;
    server_name www.maindomain.com maindomain.com trk.* *.com ; <— last one is a tracking domain starting with trk. … but you could put anything here.

         return 301 https://maindomain.com$request_uri;


This way the script is loaded through HTTPS and it just takes the request_uri.

So this should be ok …

Another way would be to put the certificates of all tracking domains on the same server as the tracking script, but then still I would have to force the tracking domain on the main domain. So, having both as HTTPS would actually only be cosmetic …

I guess for speed, the best thing would be to just put the full name of the tracking domain in there …

Okay so you have a tracking domain of, say, trk.example.com and you pointed the A record at your nginx server. Then on some website (say example.org) you have something like <script src="http://trk.example.com/path/to/tracking/script.js">? So when a browser loads http://example.org it then loads the script from http://trk.example.com, which gets redirected to https://maindomain.com and loads the script over HTTPS. Is my understanding correct so far?

If so: that's ok as long as example.org is using HTTP (though that in itself isn't ideal, obviously). If example.org is using HTTPS, then you'll have a problem because browsers will block the initial HTTP request to http://trk.example.com and you won't get a chance to redirect it.

If you can do this and make it work, it would be ideal, and should solve the problem I described above. It should even be possible to set it up without needing a redirect, at least in theory (though again I have no idea how to do it with EE specifically, sorry).

Well … to be exact. Nginx just pastes the request URI after http://tracker.com . So, basically it’s a simple rewrite from tracking domain to main domain. Thus the practical workings of the script are actually https.

To make the whole chain https i’d have to indeed install certificates on the tracker server for the different tracking domains. Then I think I’d have to create an nginx rewrite rule for the HTTPS tracking domains, with if statements, so that they load the correct certificates for the correct tracking domains …

I think that would be the ultimate set up …

Not necessarily - if you have 100 or fewer domains, you can put them all on a single certificate. If you do need multiple certificates, the more usual way to switch between them is to use multiple server blocks. (I don't even know if if statements would work at all? nginx experts?)

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