I get signals that people outside my country (nl) can not access my website. they say they see the Apache placeholder. It is just in some cases.
Is there something wrong with my dns?
m.skiweather.eu149.210.237.45A
skiweather.eu149.210.237.45A
mail.skiweather.eu149.210.237.45A
skiweather.eumail.skiweather.euMX (10)
smtp.skiweather.eu149.210.237.45A
pop.skiweather.eu149.210.237.45A
www.skiweather.eu149.210.237.45A
skiweather.eudns1.vpshosting.nlNS
skiweather.eudns2.vpshosting.nlNS
skiweather.eudns1.vpshosting.nl info#vpshosting.nl 2014081800 14400 3600 604800 3600SOA
skiweather.eudns3.vpshosting.nlNS
*.skiweather.eu149.210.237.45A
gfx.skiweather.eu149.210.237.45A
cdn.skiweather.eu149.210.237.45A
skiweather.eugoogle-site-verification=gtRAq2UWkOKRq1ITaaUuUhxqDh077OwH5aadHCX7TbcTXT
#.skiweather.euv=spf1 a mx ip4:149.210.237.45 include:_spf.google.com ~allSPF
skiweather.eu2a01:7c8:aabb:5e4:5054:ff:fe74:b8cdAAAA
Your DNS seems fine. Checking all your 3 nameservers return the same, correct, IP:
dig #dns1.vpshosting.nl skiweather.eu
dig #dns2.vpshosting.nl skiweather.eu
dig #dns3.vpshosting.nl skiweather.eu
In addition, https://intodns.com/skiweather.eu doesn't report any problems.
A problem though is that the https site (https://skiweather.eu/) returns:
Welcome to skiweather.eu
To change this page, upload a new index.html to your private_html folder
This is unrelated to DNS and regards configuration on your webserver which seems to be Apache httpd. So you'll have to check the <VirtualHost> block for port :443. You should make it look like the one for :80 (but do not remove the certificate related directives).
p.s your SSL certificate is self signed and not good. If you care to have proper https on your site have a look at https://letsencrypt.org/
Related
I am trying to get the SSL certification for my app with Heroku, but the Automated Certificate Management is failing for one of both domain names.
I created the dyno before March 2017, so I had to run heroku certs:auto:enable as explained here.
Then, heroku domains returns:
Domain Name DNS Record Type DNS Target
─────────────── ─────────────── ─────────────────────────────
example.com ALIAS or ANAME example.com.herokudns.com
www.example.com CNAME www.example.com.herokudns.com
This seems to be in line with what heroku expects.
Anyway, heroku certs:auto returns:
Domain Status
─────────────── ────────────
example.com Failing
www.example.com OK
I admit that I am quite illiterate for settings concerning domains, DNS and so on. Therefore, this might be a very simple mistake from my side. However, I read the Heroku troubleshooting documentation and also similar questions in SO such as a this one or this one and still have no clue what is wrong.
The fact that www.example.com is OK but example.com is failing just confuses me even more. And unfortunately, I received a notification email with no failure reason.
Namecheap
I guess the problem is either on Heroku or where I bought the domain. That is Namecheap.com.
There, at the Domain tab I have:
NAMESERVERS Namecheap BasicDNS
REDIRECT DOMAIN Source URL Destination
example.com http://www.example.com
And at the Advanced DNS tab:
Type Host Value TTL
------------- ----- ------------------------------- -------
CNAME Record www example.com.herokudns.com Automatic
TXT Record # google-site-verification... Automatic
URL Redirect Record # http://www.example.com/ Unmasked
What am I doing wrong?
Update
The issue seems to be due to Namecheap. I found the following ticket on Heroku:
Issue
User is having trouble pointing their root domain (aka apex
domain/naked domain) to their Heroku app, either with setting the
right DNS records, or accessing it over HTTPS.
Resolution
Root domains on Heroku require the use of "CNAME-like" records, often
referred to as ALIAS or ANAME records.
Unfortunately, a number of popular DNS hosts such as GoDaddy,
Namecheap, Bluehost, and others do not support these types of records.
Instead they tend to offer the following:
A records
URL redirects / forwarding
There are caveats with both of these options...
Surprisingly, I did not find any place where all the steps were explained clearly. What I did so far is:
Open an account with a DNS host that supports this. I took DNSimple. At the time of writing, prices start from 5€/month but there is a trial month for free.
Transfering the domain costs 14€/year, so I just pointed the name servers at Namecheap to DNSimple and added the domain to DNSimple to create the DNS records.
Then came the configuration on DNSimple. I followed the step 1 in the documentation to redirect HTTP to HTTPs; ignored the step 2, since Heroku's ACM had already done it; and for the step 3 the article Pointing the Domain Apex to Heroku was very helpful. I added manually an ALIAS record and I also added a CNAME record, like this:
Type Name Content
───── ─────────────── ───────────────────────
ALIAS example.commyapp.com.herokudns.com
CNAME www.example.commyapp.com.herokudns.com
At the beginning nothing was working and the browser showed the following error:
This site can’t be reached
www.example.com’s server IP address could not be found.
Checking the troubleshotting documentation I saw that the only possibility was the Name server propagation delay, so I waited. It felt like a very long time, but it actually took less than one hour until the site got online again.
However, the SSL certification keeps failing more than 48 hours later...
For future reference: after contacting Heroku support, they manually refreshed my certificate request and it was finally issued for my app...
Check the answer here especially the CloudFlare solution as it is free
Automated certificate management also provisions you a free SSL cert
from https everywhere. You don’t need to buy a cert.
However namecheap won’t work with ACM because they don’t allow an
“alias” record for your “apex” domain I.e. your domain with no
subdomain so https://example.com not https://www.example.com
Your options are switch to a dns registrar that supports an “alias”
record such as dnsimple. They charge $5 a month in addition to the
domain registration fee.
Or alternatively use a free cloudflare instance which comes with SSL.
If you already bought a cert there is a way to upload it to Heroku via
an SSL addon.
I use both DNSimple/Heroku ACM on some apps and cloudflare on some
others. Both are equally nice but cloudflare is free and gives you a
CDN too.
https://www.reddit.com/r/Heroku/comments/7wh5r4/setting_up_ssl_with_heroku_namecheap/
I have two domains with GoDaddy: foo.com and bar.com
I want to redirect foo.com to bar.com/foo
I tried setting up Domain Forwarding from within the GoDaddy Dashboard and it did work, but not for HTTPS (which is the URL indexed within Google).
I checked with GoDaddy Support and received this response:
That will not work because your domain does not have an SSL Certificate active and there is no way to activate an SSL Certificate on it with a forward.
Maybe I'm overthinking this, but here's an alternative approach I had in mind:
Set the A record of foo.com to the same IP address that bar.com is using
Within the website code of bar.com, check the $_SERVER['SERVER_NAME'] and redirect appropriately
By using plain DNS this is not possible, the reason for this is that DNS is a protocol different than HTTP.
Some providers offer "forwarding" options but behind the scenes, they point your domain to an HTTP server the one later does the redirect.
For example, using CloudFlare this could be very easy to achieve, you need to setup up only one domain, let's say foo.com and then just create a page rule to redirect traffic to bar.com/foo, the rule could be something like:
*foo.com*
More info about the page rules can be found here: https://support.cloudflare.com/hc/en-us/articles/200168306-Is-there-a-tutorial-for-Page-Rules-
I have a Debian server which is running a number of client sites. Most of these are not running SSL so accessing by HTTP is fine.
I have one customer with an SSL certificate and accessing their site via HTTPS is fine too.
The problem comes if you try to access one of the other sites with HTTPS you get directed to the other site that has the SSL certificate.
For instance, lets say we have the following sites on the server:
alpha.net
bravo.net
charlie.net (SSL)
delta.net
So as you can see, charlie is the only one with SSL, and irrespective of if you go to http charlie.net or https charlie.net, it works fine.
http to all the other sites is fine, but if you were to go to https alpha.net, it will initially come up with an Invalid Certificate error and let you continue but whilst it has alpha.net in the address bar, its actually showing the charlie.net site in the browser.
I have researched SNI and how if any other sites have SSL I'll need to put them all on specific IP addresses (something else I need to try to work out how to do as I have no idea) but I am not sure why this is happening or how I resolve it.
Has anyone else encountered this before and how did you get around it?
Many thanks,
Rob
This does not have anything to do with SNI, as you currently only have one HTTPS server. What happens, as you've stated in your comment, is that the alpha.net domain resolves to your server's IP. Your Apache server is set up to listen for requests on port 443 on this IP, and to serve the contents of charlie.net to these requests. (And the certificate error means that the browser noticed the discrepancy between the certificate's alleged domain name and the domain name used for the request.)
Redirecting from HTTPS to HTTP is probably more trouble that it's worth, since you would need valid certificates for each domain, lest you present your users with another security warning. This would entail creating virtual hosts for alpha.net:443 and so on, on an SNI capable server (i.e., later versions of Apache 2.2+ with openssl), and adding a redirection like so:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
Probably the easiest course for your problem is to use a different IP for charlie.net. With this setup, there would be no way for alpha.net (and so on) to display the contents of another site.
If you have multiple IPs on your server, use a unique one for the SSL site, all non-SSL sites share another IP.
Since SSL doesn't care what is the domain you are visiting, it only cares if the current domain is approved from the list of domains(Common Name) it gets from the Ip address.
I see several people describing how to do this for a custom domain with sub-domain but no one talking about how to do it without one.
Example: Setting foobar.com and www.foobar.com to point to my Amazon S3–hosted site
I personally do not want the www prefix. Is there no way to make this happen? I seems crazy that Amazon would set it up to allow static sites and custom domains, then lock it down to prefixed domains?
Thanks in advance,
For historical reasons any URL needs to resolve to a subdomain, which you already know how to handle: Create a CNAME record with your DNS provider, pointing www to your S3-hosted subdomain. There are details to get right, described nicely elsewhere.
You nevertheless want to support users who, charmed that their browsers will autocomplete http:// and .com and such, want to type a naked domain domain.com, and have it automatically complete to your default subdomain such as www.domain.com.
The easiest way to accomplish this is to use www as your default subdomain, and point your DNS provider's A record at wwwizer.com (174.129.25.170). They automatically redirect any naked domain to the same domain with www in front.
You get fastest turnaround on development, and your visitors get fastest DNS resolution, if you use Amazon Route 53 to provide your DNS services. Route 53 can point its A records to wwwizer.com. However, you may want to create a micro Amazon EC2 instance, and start programming it. In the '50s everyone rebuilt their own cars. In the '80s everyone pushed a shopping cart down the aisle at Fry's, and built their own computer. Now, you want to be able to build your own computer in the cloud, for many reasons you will discover with time, and Amazon EC2 is best choice. For now, your cloud computer will simply handle naked domains for you. Later, email, generating the static site, ...
Install the Apache web server (the A in LAMP; a LAMP server will do the trick), and configure a virtual host for each of your domains. Then point an elastic IP address at your EC2 instance, and update Route 53 to have your A record point to this elastic IP address. Amazon doesn't support having multiple elastic IPs pointing to the same EC2 instance, but you can provide the same elastic IP to multiple domain A records, and have Apache resolve this within your EC2 instance.
This takes some fiddling and experimenting, as there's lots of conflicting advice on the details. I used the ami-ad36fbc4 instance image (US East, 64 bit EBS-backed Ubuntu 10.04 LTS), as I'm familiar with Ubuntu, there's plenty of online help with Ubuntu, and this image will be supported for years. I edited /etc/apache2/httpd.conf to have the contents
NameVirtualHost *
<VirtualHost *>
ServerName first.net
Redirect permanent / http://www.first.net/
</VirtualHost>
<VirtualHost *>
ServerName second.net
Redirect permanent / http://www.second.net/
</VirtualHost>
then checked for errors using
sudo /usr/sbin/apache2ctl configtest
then restarted the Apache server using
sudo /etc/init.d/apache2 restart
Apache is standard across Linux flavors, but the details such as file locations may vary, e.g./etc/apache2/httpd.conf could be /etc/httpd.conf. For example, it might be necessary put a Listen 80 in httpd.conf, but Apache throws an error if that command was already somewhere else. So read web instructions with a grain of salt, and be prepared to Google any error messages.
As I'd already been using Amazon Route 53 for days to point to wwwizer.com, this worked immediately once I updated Route 53 to point to my elastic IP. Before switching to Route 53, each change took days for me to verify, as the information propagated across the web. Once everyone knows to look to Amazon, Amazon can propagate its internal changes much more quickly.
Unfortunately you can not point foobar.com to an Amazon S3 bucket and the reason for this has to do with how DNS works.
DNS does not allow the root of a domain (called zone apex) to point to another DNS name (you can not have foobar.com set up as a CNAME / only subdomain.foobar.com can be a CNAME)
Since this question was asked things have changed. It is now possible to host your site on S3 with a root domain.
Instead of just having one bucket named "www.yourserver.com", you have to create another bucket with the nude (root) domain name, e.g. "yourserver.com".
After that you will have to use Amazon's DNS service Route 53. Create an A record for the nude domain and a CNAME for the "www" hostname.
Note that you will need to move the domain management of your domain to Amazon Route 53 completely.
See for the detailled walk-through here: http://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html
I have a question, I fear the answer.
I have:
a top level domain name (free from Tokelau, a territory of New Zealand, .tk, where else?),
a free 2 year ssl certificate from startSSL.com,
a free hosting package.
Now I jumped through every hoop startSSL wanted (admittedly wasn't too difficult), to get me my 2 year ssl certificate, and now I fear I have encountered a final barrier to success that might still stall my plans. I dreamt of a corner certificate stating "Secured by startSSL". I got the code snippet and everythings, and have pasted it into my website.
Problem. my host is not so keen on a free package to allow me to ssl.
As far as I know you need access to some config files to allow this to happen?
or can you just like with .htaccess and .htpassword files do the setting on your webhost?
Also you need a static IP. Are there any workarounds?
Or am I dreaming? Anyone with advice?
SSL Requires some files and configuration changes, pointing to the files.
Also, the static IP is required because with an encrypted request, there's no way to know to what host the request is intended without decryption. The use of a static IP address gives that request a destination.
To clarify: when using virtual hosts, multiple hosts will share the same IP address, so when a request comes in, the first two lines are:
GET /path/to/resource HTTP/1.1
Host: www.example.com
Apache (or any web server), looks at the 'Host' field to determine how to route the request. If the request is encrypted, there's no way to determine how to route the request, and you need to know what certificate to use in order to decrypt it.
Forget it. If your host doesn't have SSL configured, you have no chance to add it without their help
There are two problems with your proposed set-up.
Free hosts generally don't provide a control panel interface to allow installation of SSL Certificates (at least I've never seen it) as this requires either their help on the back-end or VPS / Dedicated Server access from the front-end.
Static IP address is a must for SSL certificate installation.
From webserver perspective, SSL cert is about a port and an IP address, even when being used with Name-based virtual hosts.
SSL is about the IP the matching the cert and domain in the URL/request(to verify the cert).
You would have to give a second SSL cert different port or different IP address on the webserver.
Alternatively, you can also get multi-domain and wildcard certs that allow different hostnames or domains to match the cert with different client request URLs, but the cert is still the only thing on that port/IP of the webserver.
Just my $.02