I have recently acquired a domain name from GoDaddy. At home i am trying to setup a nextcloud server. Since my ISP serves me a dynamic IP addresse i had to create another domain name on no-ip website. Furthermore, i want to forward http requests to https. The following questions rises:
Do i create the ssl certificate (with let’s encrypt) for the godaddy domain or the no-ip domain?
What is the correct forwarding sequence here? Assume godaddy is foo.com and no-ip bar.dyndns.me and the user types foo.com, my server apache settings would forward foo.com:80 to :443 but this i guess should be corrected to my dyndns. I am confused.
I would appreciate any help - thank you.
you are making it too complicated. Instead of using a redirect you should request a static ip from you isp. this costs money varying by your provider but then you only need one domain. you then apply the ssl certificate to that domain and enforce ssl only with your hosting server (i.e apache, iis).
You can write a simple app/script to manage the Dynamic DNS from your server using the GoDaddy Api, thats what i have been doing for ~3 years now as my ISP want a stupid amount for a static IP. I have mine pinging out every 10 mins to check if my IP changed (ISP sucked for a while and mine would change several times a day)
Here are some links to various implementations of the GoDaddy API
BASH
Python
Powershell
So I think I have a fix for this, before I give you my answer I will outline problems with other solutions.
Static IP from your ISP. The problem with this is it may cost too much. (However if it’s cheap I’d probably do this solution)
Script and update godaddy DNS. This is okay however only if you can allow for some outage time between changes. (The DNS will take time to Propagate up to 24 hours)
Upgrade your noip account to a plus managed DNS it costs $29.95 a year. However it will allow you to bring your own domain name from another provider like go daddy. Depending how often your noip client is running there could be a very small outage between changes.
https://www.noip.com/support/knowledgebase/can-i-use-my-own-domain-name-with-no-ip/
There seems to be two places in PLESK to add SSL certificates. One location is under Domains
and another under Tools and Settings.
What is the purpose of the first versus the second location?
Both locations in PLESK (v12) accomplish the exact same thing. The one added benefit to adding the SSL under the domain name is accessing the IP address via HTTPS (answer from hosting company).
I hope it helps someone in the future.
I have a https web app running on my aws ec2 instance.
https://ec2-52-91-100-69.compute-1.amazonaws.com/
I need to get a ssl certificate for the same so that the scary warnings do not appear.
How can I do this? I tried to buy a ssl from clickssl.com but their helpdesk emailed me with the following:
"You completed enrollment process for domain name
ec2-52-91-100-69.compute-1.amazonaws.com.
I believe you cannot get SSL for this domain name because root domain
name amazonaws.com is Amazon property."
If this is the case is there no way to get a ssl certificate for my application? I dont believe thats the case.
Any help will be appreciated.
First you need to register a domain through a registrar (e.g. GoDaddy or Amazon Route 53). Next you assign an Elastic IP to your EC2 instance and use your registrar's DNS tool to make your domain point to the Elastic IP address. Then you can request an SSL certificate for your own domain.
You do need to register a domain, or use a subdomain of a domain you already have registered. You do NOT need to use an Elastic IP - they are limited and eventually (if you use multiple domains in your AWS account) you will run out. Instead, you can use a CNAME to point to the AWS name (e.g., ec2-52-91-100-69.compute-1.amazonaws.com).
Once you have that set, use Let's Encrypt to get a free widely accepted certificate. There are plenty of tutorials on the installation process - try:
https://ivopetkov.com/b/let-s-encrypt-on-ec2/
Just noticed the original question is OLD - which means (among other things) that Let's Encrypt wasn't even an option at the time. But for anyone who stumbles across this question now, it is a great solution.
I own a domain name from godaddy.
Now, I want to host the domain with SSl support.
Is it possible to get hosting and ssl certificate from two different vendors and then integrate them with my domain as i am going to have shared hosting.
Please check answer here
https://serverfault.com/questions/405750/godaddy-ssl-on-shared-hosting
Yes, you can buy domain name and SSL from two different vendors.
Note: Please must mentioned the exact domain name when buying the SSL certificate.
Please check the following also,
http://www.webhostinghero.com/install-godaddy-ssl-certificate-on-cpanel/
I'm setting up a webserver for a system that needs to be used only through HTTPS, on an internal network (no access from outside world)
Right now I got it setup with a self-signed certificate, and it works fine, except for a nasty warning that all browsers fire up, as the CA authority used to sign it is naturally not trusted.
Access is provided by a local DNS domain name resolved on local DNS server (example: https://myapp.local/), that maps that address to 192.168.x.y
Is there some provider that can issue me a proper certificate for use on an internal domain name (myapp.local)? Or is my only option to use a FQDN on a real domain, and later map it to a local IP address?
Note: I would like an option where it's not needed to mark the server public key as trusted on each browser, as I have not control over workstations.
You have two practical options:
Stand up your own CA. You can do it with OpenSSL and there's a lot of Google info out there.
Keep using your self-signed cert, but add the public key to your trusted certs in the browser. If you're in an Active Directory domain, this can be done automatically with group policy.
I did the following, which worked nicely for me:
I got a wildcard SSL cert for *.mydomain.com (Namecheap, for example, provide this cheaply)
I created a CNAME DNS record pointing "mybox.mydomain.com" at "mybox.local".
I hope that helps - unfortunately you'll have the expense of a wildcard cert for your domain name, but you may already have that.
You'd have to ask the typical cert people for that. For ease of use I'd get with the FQDN though, you might use a subdomain to your already registered one: https://mybox.example.com
Also you might want to look at wildcard certificates, providing a blanket cert for (e.g.) https://*.example.com/ - even usable for virtual hosting, should you need more than just this one cert.
Certifying sub- or sub-sub domains of FQDN should be standard business - maybe not for the point&click big guys that proud themselves to provide the certificates in just 2 minutes.
In short: To make the cert trusted by a workstation you'd have to either
change settings on the workstations (which you don't want) or
use an already trusted party to sign your key (which you're looking for a way around).
That's all your choices. Choose your poison.
I would have added this as a comment but it was a bit long..
This is not really an answer to your questions, but in practice I've found that it's not recommended to use a .local domain - even if it's on your "local" testing environment, with your own DNS Server.
I know that Active Directory uses the .local name by default when your install DNS, but even people at Microsoft say to avoid it.
If you have control over the DNS Server you can use a .com, .net, or .org domain - even if it's internal and private only. This way, you could actually buy the domain name that you are using internally and then buy a certificate for that domain name and apply it to your local domain.
I had a similar requirement, have our companys browsers trust our internal websites.
I didnt want our public DNS to issue public DNS for our internal sites, so the only way to make this work that I found was to use an internal CA.
Heres the writeup for this,
https://medium.com/#mike.reider/getting-firefox-chrome-to-trust-your-internal-websites-internal-certificate-authority-a53ba2d4c2af
i think the answer is NO.
out-of-the-box, browsers won't trust certificates unless it's ultimately been verified by someone pre-programmed into the browser, e.g. verisign, register.com.
you can only get a verified certificate for a globally unique domain.
so i'd suggest instead of myapp.local you use myapp.local.yourcompany.com, for which you should be able to get a certificate, provided you own yourcompany.com. it'll cost you thought, several hundred per year.
also be warned wildcard certificates might only go down to one level -- so you could use it for a.yourcompany.com and local.yourcompany.com but maybe not b.a.yourcompany.com or myapp.local.yourcompany.com, unless you pay more.
(does anyone know, does it depend on the type of wildcard certificate? are sub-sub-domains trusted by the major browsers?)
Development purpose only
This docker image solves the problem (thanks to local-ip.co): https://github.com/medic/nginx-local-ip.
It launches a reverse proxy in the port 443 with a public cert that works with any *.my.local-ip.co domain. Eg. your local IP is 192.168.10.10 → 192-168-10-10.my.local-ip.co already points to it (it's a public domain)! Assuming the app is running in your computer at the port 8080, you only need to execute this to proxy pass your app and expose it at the URL https://192-168-10-10.my.local-ip.co:
$ APP_URL=http://192.168.10.10:8080 docker-compose up
The domain is resolved with any public DNS you have configured in the devices where you want to access the app, but your traffic keeps local between your app and the client (through the proxy), so you can even use it to connect with devices within the same LAN network, without any of the traffic going out to internet, all the traffic is local.
The reason that is mostly useful for development is that anybody can launch an application with this same certificate, so is not really secure, but helpful when you need to expose your app with HTTPS while developing or testing (e.g. HTML5 apps in Android that are loaded with Webview).