4

I've never seen this configuration in .htaccess. This comes from my site that currently reset. I have no SSL certificate installed, but I remember seeing these names on previous certs though.

So does anyone know what this accomplishes?

RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{HTTP_HOST} ^example\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^/?$ "http\:\/\/www\.example\.com\/" [R=301,L]
  • "my site that currently reset" - what do you mean by "reset"? – MrWhite May 14 '18 at 14:45
  • They supposedly wiped out the system container, then reinstalled the web server on it. It deleted all domains, sub domains, databases and all settings. It brings it back to day 0 when I bought it. – drtechno May 14 '18 at 15:27
4
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$

I have no ssl certificate installed

Well, you probably do now!? These (type of) conditions are injected automatically by cPanel when it auto-renews the (usually FREE) security certs (eg. those provided by "Let's Encrypt"). This is to ensure that the validation file (required during installation) can be accessed.

Some (shared) web hosts now appear to enable these free SSL certs whether you explicitly requested them or not.

See my answer to a similar question over on ServerFault for more details:
https://serverfault.com/a/884922/49157


Aside:

RewriteCond %{HTTPS} on

You say you didn't have an SSL cert installed, however, you were attempting to perform an HTTPS to HTTP redirection (which would be pointless without an SSL cert, but also backward if you did).

RewriteRule ^/?$ "http\:\/\/www\.websitename\.com\/" [R=301,L]

This only redirects the single request for the document root - is that intentional? However, in your exemplified code, this looks like it would result in a redirect loop?!


UPDATE: Maybe you were after the bigger picture...?

RewriteCond %{HTTPS} on
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{HTTP_HOST} ^example\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com$
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule ^/?$ "http\:\/\/www\.example\.com\/" [R=301,L]

There is nothing particularly strange here. These is just two incompetently written redirects, which will likely break your server (unless something has been lost in the exemplified code in your question):

  • The first is an HTTPS to HTTP redirect. Although you have to ask why? You would need to have an SSL cert installed in the first place to avoid browser warnings. And if you have an SSL cert installed then why not use the SSL cert? (But then, maybe your site isn't HTTPS-ready?) However, because of the lack of the R flag, this will result in a temporary (302) redirect. Also, the absence of the L flag will allow the rewrite engine to continue through the file.

  • The second looks, at first, like a canonical non-www to www redirect (which, incidentally, looks as if it was generated by cPanel - the unnecessary abundance of backslash escapes in the RewriteRule substitution is a telltale sign). However, the additional condition that checks against the canonical hostname will result in a redirect loop! It also only redirects the document root.

  • The two other conditions (RewriteCond directives) mentioned above are added automatically by cPanel when SSL certs are renewed.

  • I notice this today, but I also noticed that the Sitelock guy logged into cpanel (so he must have done this? ) or its something that what ever was done in cpanel caused this. I noticed the https of this site stays in a loading state and never times out nor gets redirected. I guess he was trying to resolve everything to the index page using http. But isn't there a better way to do that at the nameserver with the correct dns entry? Or is this something they stuck in to prevent the unknown server that was attaching and using 2gb of data daily on that site before the reset. – drtechno May 14 '18 at 14:40
  • Who is the "Sitelock guy"? If you have someone else administering your cPanel account then yes, they may have done this. Or, as mentioned above, some web hosts do this automatically (without having to login to cPanel). "I noticed the https of this site stays in a loading state" - maybe your site is not HTTPS-ready? "But isn't there a better way to do that at the nameserver with the correct dns entry?" - what, redirect? "Or is this something they stuck in to prevent the unknown server that was attaching and using 2gb of data daily on that site before the reset." - Not sure what you mean? – MrWhite May 14 '18 at 14:54
  • It used to have ssl certificates installed. But apparently the host I had had the indexing option turned on and they had empty directories that were not protected. In the awstats a few months ago, someone url surfed the drive (saw ..\..\ssl or something like that) and after that, the daily average bandwidth went from 200K to 2.5Gb. I had the feds on that webserver but the only thing I saw what they did was just copy everything that was on the drive. – drtechno May 14 '18 at 15:15
  • I had it reset, but it installed some self signed certs with *.webhost.com as the url and as a result, the web browser error showed both private and public server certificates. The self generated certificates were deleted, and this appeared in the htaccess file. – drtechno May 14 '18 at 15:16
  • I'm just wondering if this is a new tactic someone brewed up to send the dark web server that was stealing bandwidth into an infinite loop. So it wouldn't establish a connection @ that url. – drtechno May 14 '18 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.