I am setting up a WebDAV server behind traefik using docker compose. Also,I want to add HTTPS support to it, so that keeping my data private. I bought a domain name and prefer to use Let's Encrypt, because it's free of charge.
But as far as I know, Let's Encrypt requires TLS, HTTP or DNS challenge. While last option seems only for big companies who owns the public DNS server, other two options need port 80 or 443. The problem is that these 2 port are all blocked by the ISP. So is there any workaround? How to make it work?
While last option seems only for big companies who owns the public DNS server
If you own the domain, you should have full control over the DNS records — free of charge, by going to the vendor you bought the domain from, and finding the section for the DNS controls. If you have your domain pointing your IP address, you've already used it, probably by adding an A or AAAA record. Let's Encrypt DNS challenge requires only a TXT record, which should be available on virtually every domain registrar's DNS controls.
I have a Windows instance from GCP Compute Engine. I have a website on the server using IIS, for a time. It is perfectly working with SSL certificate.
Yet, now we want to host another website on the server. I had opened the website yesterday, all the DNS's are configured and it is also working
well expect it has a HTTPS connection. I bought a SSL certificate and it is issued and ready for use. However, I forget that IIS works with SSL's in a way that the most recent SSL is accepted for specific IP and all the websites would start consuming that, the newest, one. That is why I was trying to obtain new IP but could not figure it out. Then I simply tried traditional way to have a new IP and wanted to assign to new site. Then on IPv4 configurations, it says 'DHCP Enabled'. So I stuck there and could not go to the next steps.
GCP have really complicated documentations on this issue none was really clearly expressing it. I found some solutions like I might start with enabling IP Forwarding yet I also could not find on documentations how to do it.
In short, I had a website with SSL and I have opened a new website on the same machine. Of course, their IP's are same so I would like to be able to obtain a new IP without changing the previous site's IP. I just did not know and could not find how to do it.
I would be appreciated if someone can help me to figure out how to obtain new IP for the new site so that I can use my issued SSL certificate for the website.
Thanks!
It is not directly possible to assign more than 1 IP per VM. However, you can have any number of external IP addresses by referencing the instance through forwarding rules and target pools, which is explained in this document.
You may also work out this without lb but only with forwarding rule / Protocol Forwarding. More about the concept is discussed here
Good Afternoon,
I wanted to ask this question regarding SSL certificates. Our company manages several servers. For example:
location1.domain.com
location2.domain.com
location3.domain.com
Each of the links goes to a different server with different IP as it pertains to connecting to the system from the outside world. And at each location, there are browsers that connect to each server on the local network to the same network.
For example:
192.168.2.130
The server is an apache2 running ubuntu server 14. In addition, in all the tutorials that I have looked at, one needs to know the IP address of the machine. With many of these locations, the IP address often changes. They have dynamic IPs. What I was wondering is what kind of SSL certificate do I need? I thought about the wildcard certificate but did know if it was an overkill. I also would like for the location users within each location to not see the error message that comes from not having a correctly signed SSL certificate. Thanks in advance.
George
Unless the number of location is constantly changing, you don't need a wildcard certificate. Just get one per location. Certificates should always be assigned to a name, not ip, so how the request is routed doesn't really matter.
If the internal users actually connect via IPs, rather than names, that's something you need to fix, because you have to bind the certificate to a stable name. If you want the internal users to skip the global routing, you can use something like split-horizon dns for it. (basically you serve your local users different dns answers than the ones you publish to the internet)
Maybe it is just impossible but I have the following question :
I own an domain for example : mydomain.com . On that domain I take a wildcard SSL. So far no problem. And that domain is running on a server with online software on a sub domain for example soft.mydomain.com.
Now I have customers for that software, and I want to customize the software to their subdomains for example soft.customer1.com and soft.customer2.com.
I can do this by letting them make a DNS A record pointing to my servers IP and I park then the domains onto my subdomain soft.mydomain.com (Tested that and it works).
The question is now : Can I also take a SSL certificate on soft.customer1.com and soft.customer2.com. So that at least I also have a secure connection when for example soft.customer1.com/login.php is used.
If possible who has to request the actual SSL certificate in that case.
Also I have full access to WHM and cpanel, running a VPS.
I understand that I could use customer1.mydomain.com/login.php , but I wonder if it just would be possible to do what I suggest.
And also it recommended to work in this way ?
Thanks upfront.
Regards,
Peter
Different domains can exist on a single SAN/UC certificate. Take a look at http://www.ssl.com/certificates/ucc to learn more about this certificate type.
It sounds like you have all the pieces except for this particular certificate. I hope it helps.
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).