I am developing an https-based web server on my machine. This currently works with a self-signed certificate. Of course, my browsers complain about it, but it is okay for me to skip this check and accept my very own certificate.
Now I would like a co-worker to be able to access my https server as well. My machine does neither have an internal host name setup nor a static IP address.
Of course, if I create a certificate for localhost, it will not work for him - as localhost for him is his machine, not mine.
How can I solve this issue?
Is the only way to assign a static IP address or to setup a host name? Is it possible to get a certificate that matches any IP and / or hostname?
(Please note that I know that this is quite counterintuitive to what certificates are meant for, and I highly doubt that you will find someone trust-worthy who issues a certificate for anything, but I still have hope ;-). At the moment, we do not need it for authentication, just for testing. We would replace it with a valid certificate later on.)
You can issue a certificate to multiple Subject Alternative Names (e.g. localhost, machine001.local and 192.168.0.15). Note that, for IP addresses, the SAN must be of type IP address. Most tools that let you do this will let you specify the type (XCA is one of them for example).
I'm not sure how your co-worker can access your machine if it doesn't have either an internal host name or a static IP address. Perhaps you could use something like mDNS to give it a .local name anyway. Alternatively, you can use dynamic DNS services. They would also work even if they resolve the DNS to an IP address that is only routed on your LAN.
Ideally (since you don't want to use a commercial CA), you should create a CA (again, XCA can help) and distribute your CA certificate to your co-workers. In this case you wouldn't even have to add exceptions.
Having a certificate that matches any IP address or hostname wouldn't work. You normally can't have wildcards with IP addresses, and most browsers require more than one "label". Some implementations even make sure you have enough to fall within the scope of an actual domain (e.g. *.something.com or *.something.co.uk).
(Some browsers would let you add exceptions that also comprise the name mismatch (Firefox is one of them), so in this case, the names are not particularly relevant.)
Related
I am quite new to ssl stuffs but I am afraid I can guess the final answer of the following problem/question:
We are building hardware (let's call them servers) that WILL have IP address modifications along there lifetime. Each Server must be reachable in a secured manner. We are planning to use a TLS 1.3 secured connection to perform some actions on the servers (update firmware, change configuration and so on). As a consequence we need to provide the server's with one certificate (each) so that they can state their identity. PKI issue is out of the scope of this question (we suppose) and we can take for granted that the clients and the servers will share a common trusted CA to ensure the SSL handshake goes ok. The server's will serve http connection on there configured (changeable) IP addresses only. There is no DNS involved on the loop.
We are wondering how to set the servers' certificates appropriately.
As IP will change, it cannot be used as the common name in the server's certificate.
Therefore, we are considering using something more persistent such as a serial number or a MAC address.
The problem is, as there is no DNS in the loop, the client can not issue http request to www.serialNumberOfServer.com and must connect to http://x.y.z.t (which will change frequently (at least frequently enough so that we don't issue a new server's certificate at each time))
If we get it right, ssl handshake requires to have the hostname (that's in the URL we are connecting to) matching either the commonName of the server's Certificate or one of its Subject's Alternative Name (SAN). Right? Here, it would be x.y.z.t.
So we think we are stucked in a situation in which the server cannot use it's IP to prove its identity and the client wants to use it exclusively to connect to the server.
Is there any work around?
Are we missing something?
Any help would be very (VERY) appreciated. Do not hesitated in cas you should need more detailed explanation!
For what it's worth, the development environment will be Qt using the QNetworkAccessManager/QSSlstuffs framework.
If you're not having the client use DNS at all, then you do have a problem. The right solution is to use DNS or static hostname lists (/etc/hosts, eg, on unix* or hosts.txt on windows eg.). That will let you set names appropriately.
If you can only use IP addresses, another option is to put all of your IP addresses into the certificate that the server might use. This is only doable if you have a reasonable small number of addresses that they might get assigned to.
Or you could keep a cache of certificates on the server with one address for each, and have part of the webserver start process to select the right certificate. Requires a bit more complex startup.
Edit: Finally, some SSL stacks (e.g. openssl) let you decide whether or not each particular verification error should be accepted as an error or that it can be ignored. This would let you override the errors on the client side. However, this is hard to implement properly and very prone to security issues if you don't bind the remote certificate properly it means you're subjecting yourself to man-in-the-middle or other attacks by blindly accepting any old certificate. I don't remember if Qt's SSL library gives you this level of flexibility or not (I don't believe so but didn't go pull up the documentation).
Went back on the subject 9 mont later!
Turns out there is an easy solution (at least with Qt framework)
Qt's QNetworkRequest::setPeerVerifyName does the job for us. It allows to connect to an host using its IP and verify a given CN during SSL handshake
See Qt's documentation extract below:
void QNetworkRequest::setPeerVerifyName(const QString &peerName)
Sets peerName as host name for the certificate validation, instead of the one used for the TCP connection.
This function was introduced in Qt 5.13.
See also peerVerifyName.
Just tested it positively right now
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)
So as I understand it intranet ssl certs will no longer be available from 2015, instead to get around this I could generate my own certificates for use and install them on the networked machines. My question is, in that case, does this mean issuing my own certificates would be bad practice? I can't think of any other solutions.
Presumably, by "intranet certificate", you mean a certificate that's issued to a local host name (e.g. "sqlserver" or "mail") or a private IP address.
There's one simple solution to this: use fully qualified domain names, even in an intranet. The clients connecting to your intranet servers will need to use the FQDNs too, but that's generally not very difficult. There's also nothing to prevent you from making your DNS resolve myinternalserver.mycompany.com to any IP address you'd like, including private IP addresses, even if the DNS servers are hosted outside your company's network. (For SSL/TLS verification, you don't even need reverse DNS to work, so that's not a problem.)
Managing your own CA is also a solution, but it can be quite a bit of administrative burden (depending on the size of your environment).
(From a security point of view, I think these intranet certificates shouldn't really exist anyway, since two completely different entities may be issued with distinct certificates valid for the same (relative) identity.)
I generated a self signed certificate on IIS 7.5. It got generated against the machine name. At present I am testing my website over the IP address. On accessing it on Chrome over https I get a message, "You attempted to reach IP Address, but instead you actually reached a server identifying itself as Machine Name".
How can I ensure that the certificate can honor both the Machine Name and the IP address?
If in case both cannot be honored, how can I make it honor the IP address only?
You should create a certificate with multiple Subject Alternative Names. What you put in the CN at that stage doesn't really matter (it's only a fallback solution when there are no SANs), but putting the host name should help you identify the certificate in various lists.
Note that the entries for host names should be of dNSName type, but the entries for the IP address should be of iPAddress type, so you need a certificate creation tool that supports both. There are more details in this question (not specific to Java).
Note that IP addresses can be OK in a development context, but host names are often better anyway. Few (if any) CAs will issue you with a certificate tied to an IP address.
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).