Can you have an alias for a subdomain with a ssl cert - ssl

I have a wildcard certificate for our domain. *.domain.com
We host multiple sites on our one server using host headers with subdomains. In this specific case lets use site1.domain.com the site has a https binding on the hostname with the wildcard ssl cert.
for marketing reasons we want to rename the sites URL / Name. for example awesomewebsite.com
But for hosting and ssl certificate reasons we cant simply change the host headers on the site.
So my question. Is there a way for me to make awesomewebsite.com an alias tohttps://site1.domain.com so that the user can operate and use the site as if it was hosted at awesomewebsite.com and for security reasons all requests are actually sent to https://site1.domain.com
I have both the domains with 'dyndns.org' I know they offer some added services. Not sure if that will be of any user to me?
Also if I can obtain this are there any security concerns or other issues which might be introduced.
When using webhop feature in dyndns.org i get the following error:
Refused to display 'https://site1.domain.com/Account/Login?ReturnUrl=%2F' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'

So my question. Is there a way for me to make awesomewebsite.com an alias tohttps://site1.domain.com so that the user can operate and use the site as if it was hosted at awesomewebsite.com and for security reasons all requests are actually sent to https://site1.domain.com
The validation of the contents of the certificate is done against the name in the URL, which means that your certificate must contain the alias name too.

Never answered properly.
For whom who ends up here during a search:
What you need is a certificate (requested) with alternative names, meaning it contains all the variances you desire of FQDN/DNS names. They do not need to match or belong to the same domain. Also ideal for external name and system internal names (e.g. www.mystuff.com, host123.myhost.com):
https://www.digicert.com/subject-alternative-name.htm

Related

DNS records cannot be found for SSL certificate using custom domain on GAE

I am trying to add a custom domain to GAE but Google is struggling to issue an SSL certificate for the naked domain, as it says the DNS records could not be found.
I have tried to map both the naked domain and the www subdomain. When I entered these in the GAE custom domain section I was given 4xA records (above), 4xAAAA records (above), and 1x CNAME record for the www subdomain.
I've entered all of these records at GoDaddy.
The www subdomain in GAE was able to verify the DNS records relatively promptly but the naked domain has not been able to for 4/5 days now.
When I use a DNS lookup tool to check the A records, for the naked domain I see:
...and the four records provided by GAE are there (the other two can't be deleted or edited at GoDaddy). So why is GAE saying the DNS records cannot be found?
And when I use the same tool to lookup the www subdomain I see:
...which I guess must be correct as the certificate has issue without any problems.
If I remove the naked domain from GAE custom domain mapping then users just see a Google generated 404 error message saying the URL was not found on their servers.
Without the SSL, I can navigate to the naked domain using HTTP and I get redirected to the www subdomain (not sure if this is GoDaddy domain forwarding or Django PREPEND_WWW in action - both are setup). But if I try HTTPS on the naked domain, I get a page cannot be displayed due to failing to establish a secure connection, therefore I really need to get to the bottom of the SSL issuing problem.
I am not sure where I am going wrong and would appreciate some suggestions.
The traffic is confused, that is why the naked domain is not working because it was pointing to 2 separate vendors (server) by using the A record one from godaddy and another one from GAE. What you are doing is correct by adding the A record from GAE to your godaddy DNS. However the A record from godaddy must be deleted.
Based from this link possibly there is a forwarding setup wherein your domain is lock from the godaddy’s A record. It was also mentioned in the link that if you don't have forwarding setup, you can reach for their assistance on this link
Another possible concern is that a preset has been set on the account that permanently forwards your domain. It was suggested to remove the preset or change the settings of the preset to unlock the A record.

Allow users to use custom domain to my cloudfront app

I have a cloud front app with domain xyz123.cloudfront.net.
This CloudFront is then mapped to domain sub1.mydomain.com. For this, I followed these steps.
Added SSL through AWS CloudFront pannel to *.mydomain.com
Added A Alias record in Route 53 to xyz123.cloudfront.net
This makes sub1.mydomain.com work perfectly over SSL.
Now, I want to allow my users to use their own domain (eg sub1.userdomain.com) to access the app.
This is similar to what UptimeRobot allows in its public status pages.
What I tried, but not working
Added CNAME to sub1.userdomain.com pointing to xyz123.cloudfront.net, I get SSL Error
Added CNAME to sub1.userdomain.com pointing to sub1.mydomain.com, I get SSL Error
Added CNAME to sub1.userdomain.com pointing to xyz123.s3-website.ap-south-1.amazonaws.com (S3 Static Hosting URL)
Question
How does UptimeRobot (or GitHub Pages) allow users to add a custom domain to their status page over SSL
What is the prerequisite to make this happen?
From https://github.blog/2018-05-01-github-pages-custom-domains-https/:
We have partnered with the certificate authority Let’s Encrypt on
this project. As supporters of Let’s Encrypt’s mission to make the
web more secure for everyone, we’ve officially become Silver-level
sponsors of the initiative.
Github pages create a single certificate, from Let's Encrypt, for both your custom userdomain.com and YOURNAME.github.io. This is possible with a SAN certificate (Subject Alternative Name, https://support.dnsimple.com/articles/what-is-ssl-san/).
You can't associate more than one SSL certificate to a CloudFront distribution but ACM (AWS Certificate Manager) supports up to 10 subject alternative names. To mimic Github Pages you have to know the user domains beforehand or create a new certificate each time you add a new domain to replace the old one.
Unfortunately, there is no way to add more than 10 custom domains to a SSL in AWS.
Which is a prerequisite to having a custom domain to your cloudfront.
Hence, a workaround this could be as below.
1. Create a S3 single bucket which hosts your code
2. Create Multiple Could front distributions connected to single S3 Bucket
3. Then, add custom domains to these cloud front.
You will also need to think about CORS settings in your API of the app to allow requests from these custom domains.

Pointing GoDaddy DNS to GitHub page uses http over https

I have my DNS settings as shown in the image
DNS Setting along with an additional CNAME with host www and value as my GitHub page. Next I setup a CNAME entry in my GitHub page with an apex entry to my domain. The issue I face is that whenever I visit my domain with an https protocol, it shows a warning that the connection is not secure. I get the following in Chrome:
NET::ERR_CERT_COMMON_NAME_INVALID
How do I fix this? I have both https and http access for my domain.
UPDATE: Github introduced custom domain support for HTTPS on May 1, 2018.
If you are using GoDaddy and want to upgrade to HTTPS, do the following:
Go to DNS settings for your site in your GoDaddy account.
Remove all existing A records.
Open a terminal and do dig +noall +answer <YOUR-USERNAME>.github.io. You should see a table listing 4 slightly different IP addresses:
On GoDaddy, create 4 new A records, each one pointing to one of the IPs. For host use # and set the TTL to a low user-defined value (if you are in a hurry).
Go to your page repository settings on Github, and clear the custom domain name and save. Wait a while (minutes).
When executing dig +noall +answer <YOUR-CUSTOM-DOMAIN> yields the 4 IP addresses that you entered in the A records, go back to the Github repository settings and re-enter and save your custom domain name (which you just cleared) in the custom domain cell.
Optionally, check the box Enforce HTTPS. But make sure that https://<YOUR-DOMAIN>is responsive first.
Make sure you have a CNAME record in your DNS settings also. Host should be www and it should point to your <YOUR-USERNAME>.github.io.
Make sure there is a file in your website repository named CNAME containing the name of your custom domain (in my case ulfaslak.com).
Reference
EDIT: Please see answer below by Arturo Herrero: https://stackoverflow.com/a/50203412/462015
GitHub pages does not support HTTPS for custom domains.
The only work around for doing so is to use an SSL provider as the middle man, such as Cloudflare. However, this would involve pointing your DNS name servers at Cloudflare's, which takes some time and complicates things.
If you want HTTPS support using GitHub pages you'll have to use GitHub's provided URL instead of your custom domain.
Another great option for static sites if you want custom domain name HTTPS is Amazon Web Services. You could set up an S3 bucket for your static website, configure CloudFront to distribute the static content, point your domain name at the CloudFront distribution, and use a free SSL certificate from Amazon's cert manager. This option comes out to less than $1/Month with a low-traffic website. A great in depth tutorial for that would be here.
I hope this answered your question! GitHub pages is a great hosting option, and it's not the end of the world if you decide to forget about HTTPS.
Custom domains on GitHub Pages gain support for HTTPS since May 01, 2018
https://blog.github.com/2018-05-01-github-pages-custom-domains-https/

htaccess redirect to shared SSL

Apologies if this is a duplicate, but I couldn't find a question fitting my exact circumstances.
I am redesigning a site, part of which will require SSL coverage. I have set up SSL with our hosting provider, but this is shared SSL. Whereas our current site is at www.companyname.com, the secure server is at companyname.genericssl-host.com.
I believe the best way to proceed is to simply shift all the web files onto the secure server, whether they need to be secure or not, then redirect www.companyname.com to there. However, the provider informs me that if I do that, the URL in the browser address bar will still read companyname.genericssl-host.com once the redirect completes, and that I would need to edit the htaccess file to make it read good ol' www.companyname.com again.
What does the htaccess file need to contain in order to do this?
Not sure what your hosting provider is referring to, but changing it back to "www.companyname.com" defeats the purpose of using SSL at all. What shows up in the browser's address bar is:
what host the browser is going to send a request to
what URI it will request
the query string if there is any
If you change it back to www.companyname.com, it's going to send a non-SSL request to that host, which defeats the purpose of redirecting it to SSL in the first place.
You need to buy a certificate for *.companyname.com and install if on a host specific to your server.

How does SSL work on two connected domains?

I've read through related questions but couldn't quite find what I am looking for.
I have set up a domain just as "domain.com" and created two subdomains "client.domain.com" and "client-intern.domain.com". Further, there is a redirect active for "client.domain.com/intern" pointing to "client-intern.domain.com".
If I buy a single SSL certificate for "client.domain.com", will the data transfer also be secured when the client is going to "client.domain.com/intern"?
Or do I have to purchase a second certificate for "client-intern.domain.com"?
Thanks in advance for clarification,
Paul
UPDATE: If entering "client.domain.com/intern" into the web browsers address bar, this address remains there and the browser shows the content of "client-intern.domain.com" nonetheless.
You need a wildcard certificate to cover multiple subdomains (in your case domain.com, client.domain.com and client-intern.domain.com). Some CAs might offer you an option to include one or two subdomains into the certificate (as alternative name field) for free or for a small additional fee, but this is CA-dependent and in general the right way is a wildcard certificate. You can read about wildcard certs here (GlobalSign site).