Someone hijacking my domain via secure cert?

[dgmweb]

I've never run into this before and neither my hosting or registrar is of any help, they just tell me to create nameserver entries and allow 24-48 hours to take effect, yadda yadda - so asking for advice here. Looks like someone has an SSL cert for a domain I own and I can't get it to resolve to my site. I hand reg'd the name about 2 months ago. I have it setup on my hosting. I have created ns1 etc and all the other usual records - except SSL - I can't install a cert because:

When I point the domain to the ns1 and ns2, it will not direct to my domain - it goes to someone else's site. Can't use either the http or the https URL. Last month it was going to a page selling a blackjack book, this month it's a bitcoin site. WTF.

When I use the registrar's (Exabytes) parked page, it works fine but as soon as I try to use my own nameservers, I get a scam site. I'm at a loss here. Have tried everything I can think of. Any ideas?

Thanks!

 

[MasterOfMyDomains]

@exa-Edward is in charge of exabytes. Maybe he can come here and help you out

 

[Satyasai Ray]

My 2 cents: This looks more of a technical issue to me.

Your first line of defense is the Certificate Authority.
They shouldn't let certificates be signed inappropriately. Each CA has its own mechanism for verifying your entitlement to purchase a cert for a given domain, but typically it includes having you do one or more of the following:

• Verify ownership of the email address listed in the WHOIS info for the domain.
• Verify ownership of an email address that follows one of several predetermined patterns on the domain (e.g. "administrator@{domain}")
• Create a specific DNS record on the domain
• Make a specific change to the website hosted at that domain

But with as many CAs as we have, a surprising number of inappropriate certs get issued. This is a case of, "you had literally ONE job," but we have to accept that mistakes will happen.

Source: Stackexchange​

 

[wakguano]

i think you should let these pros know your domain name before they can put their 'detective hat' on.

is it possible?

 

[dgmweb]

Thanks all - I'm headed to a meeting this morning but will contact Edward shortly after.

@wakguano - sure, no big secret domain or anything, just commercevideos.com.

 

[Michael M]

No one is hijacking your domain "using SSL." Your issue appears to be with your configuration.

I only did a brief look at your setup, and do not use siteground hosting (which I imagine is what you are trying to do)

It appears you setup ns1.commercevideos and ns2.commercevideos to point to a DNS server that you are not in control of. It appears you have your domain at tucows. You should leave your DNS servers as Tucows defaults, and then use the A records to point the individual subdomains (www, and the default (blank parent) on the commercevideos domain)

(or you could point to your hosting service providers NameServers and then use their DNS manager to point your A records)

You should not be changing your nameservers to ns1 and ns2 of your own domain unless you actually are hosting a nameserver on those IPs. Even in that case you generally do not point your nameservers to a subdomain of the domain. You typically would use a completely different domain (or actually possibly multiple) for redundancy.

I tried to explain without getting too technical, so not sure if this helps much at all. But put simply, your issue is in your nameserver configuration - and nothing to do with SSL.

(SSL is not another way to point a domain. The SSL resides on the server that YOU point to by configuring your nameservers and DNS settings correctly)

 

[wakguano]

yes . misconfiguration i believe

at your registrar . point your domain to siteground nameservers ( never used it actually )



"someone else's site" is using siteground too ... same as your ip

 

[Michael M]

yes . misconfiguration i believe

....

"someone else's site" is using siteground too ... same as your ip

Exactly. It appears he has tried to point his NS servers to his actual IP that siteground has given him for his site. It appears it just so happens siteground hosts their DNS servers on that IP (if not others). So by setting it the way he did he is actually getting to sitegound's DNS server. But, since he didn't setup his zone file at siteground, and the IPs seem to be shared (which is normal), siteground is serving up someone else's site.

He really needs to point at the correct siteground DNS servers for his nameservers and setup the zone file at sitegound and the site should start resolving correctly within a couple of hours after the DNS propagates and his local cache is cleared. (defined by the TTL set in the record, or by manually refreshing his cache)

At least that's how it all appears from a 30 second look.

 

[dgmweb]

@Michael M @wakguano - thanks so much, I initially assumed it was my error, but my other domains on this host were setup the same way.

I deleted the domain from siteground and am going to re-add, I apparently misconfigured something on the initial add that I don't know I did.

Thanks again I'll post back once I figure out where I went wrong with it

 

[xynames]

On apache and other servers, if say there is only one SSL certificate for one of your domains in a situation where you have multiple domains on that server, if you enter the https in front of any of your domains, it can be forced to land at that one domain that has the SSL. Odd behavior, but the way some servers work.

 

[Michael M]

On apache and other servers, if say there is only one SSL certificate for one of your domains in a situation where you have multiple domains on that server, if you enter the https in front of any of your domains, it can be forced to land at that one domain that has the SSL. Odd behavior, but the way some servers work.

Basically, in the past it was one SSL per IP address, whereas you could always have multiple websites per IP. Therefore when you would navigate (using https://) to a domain on that IP that did not have the SSL configured for that domain, you would receive the certificate (and probably site) for whatever domain that was assigned to the IP - not the domain you visited.

To put it (kind of simply), the server did not know what domain you wanted a certificate for because the client could not tell it - so the server only looked at the IP binding.

It seems like odd behavior, but it was actually just the ways things were programmed that a site that used SSL should be hosted on it's own dedicated IP to avoid this possible issue.

In recent times, SNI was introduced - where the hostname is passed during the handshake process so multiple SSLs can be on a single IP. While this technology is becoming more implemented with each update on software - it still requires the browser and the host to be using the updated technology for it to work. So in theory this problem would be a thing of the past, but it still exists due to outdated software or lack of implementation on the server or client end.