I'm working on a project where I have to use self-signed SSL certificates with SAN defined.
Using common name only does not work, because the client requires SAN too, else it throws an error. However the IPs are not fixed or predefined for deployment, so there's no way to know IPs prior to deployment
Is there any tricky way where the SAN is specified, still the certificate works across multiple IPs?
I have not tried any solution yet.
Is there any tricky way where the SAN is specified, still the certificate works across multiple IPs.
One can give multiple IP addresses as SAN. But one cannot use wildcards in IP addresses, only with domains. Depending on the exact use case it might be possible to use a domain name instead which gets mapped to different IP addresses. In this case the SAN contains only the domain name.
Related
I have below domains, buying a single wild card certificate beneficial? Or do I need to buy separate SSL certificates.
abc.example.com.au
abc.example.com.nz
abc.api.module.example.com
abc.api.global.example.com
Do I need to consider anything, when buying the SSL for the above domain. Appreciate your inputs.
Probably a better question for ServerFault or SuperUser, but since you're here, a wildcard certificate will only work for subdomains and only one level deep, so it would not work for any of the examples you mentioned.
Example: A cert with cn=*.example.com would work with a.example.com or b.example.com, but not 1.a.example.com. See https://en.wikipedia.org/wiki/Wildcard_certificate for more details.
Also, when using a wildcard does make it simpler to manage your certificates and renewals and applying updated certs and whatnot because the generation process only has to be done once and the same files and configs can be copied to all servers. Consider though that, if there is some kind of security issue with the wildcard cert, then it would affect all servers that use that cert. So a breach on one server would affect all servers and a problem with one would require an update to all servers that use it.
For these reasons, I generally use wildcard certs for non-production systems, and individual certs for production systems.
Single Wildcard SSL Certificate will not work in your all sub-domains.
You have now 3 options.
Get two different wildcard domains
Get a Multi Domain SSL (it will allow you to add sub-domains as well)
Get a Multi Domain Wildcard SSL Certificate (combination of 100 multiple domains and unlimited number of level-1 sub-domains).
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)
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.)
We currently have a single development environment with Cloud66. We are hoping to expand to staging and production environments which will be secured with SSL.
Is it possible to use the same wildcard certificate to secure all three environments (obviously with different names for each)?
I've added the detail below as I don't think my original question was clear enough.
Specifically what I want to know is if Cloud66 will allow a single wildcard certificate to be used to secure domains across a number of stacks or if a single certificate can only be used on a single stack.
Yes. When you order a wildcard SSL certificate you can use it to secure multiple sites assuming they each use the same base domain of the wildcard certificate.
Yes you can, Wildcard SSL certificate is used to secure multiple domain names but your main domain name will be same.
Using wildcard you can secure
www.yourdomain.com
blog.yourdomain.com
login.yourdomain.com
secure.yourdomain.com
etc.yourdomain.com.
I have some questions about Multi Domain SSL Certifiations that I'm struggling to find answers to on the Net.
What options are there for a large number of Domains (say 500) to run under one SSL Cert?
Does anyone know any that cater for a large number like 500 Domains?
If not what are the larger Multi Domain SSL Certs avaliable? 200?
Can domain names be switched on the fly (eg: add one or remove one) or must they be setup at the beginning?
If you want to put multiple domains into a single certificate you have to use subject alternative names. While there is in theory no limit on how many SAN you can use (ok, there is a size limit of the certificate) in reality CAs set the limit to about 100 (maybe more if you pay more). To reduce the number of SAN you can use multiple wildcard domains (*.example.com). If this still does not help you can use multiple certificates on the same IP if client and server support SNI (Server Name Indication), all current browsers should support this and most current web servers.