Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have an SSL assigned to my main domain and I'm wondering if I can use the SSL to my sub-domain!! I frankly tried it out, but it shows warning page saying that this page is not safe or so on. Is there a solution to this so I can use the SSL on my sub-domain to let clients send their info on a secure connection.
The error message " This webpage is not available"
X.509 certificates (often called "SSL Certificates") are usually only bound to a single domain, usually mydomain.example, www.mydomain.example or secure.mydomain.example. They cannot be used on any other domain name, even if it's a subdomain (so a certificate for mydomain.example cannot be used for www.mydomain.example and vice-versa).
There currently exist 2 other types of certificates which can be used to simultaneously secure multiple domain names simultaneously:
A relatively new type of certificate called an "SAN Certificate" - short for "Subject Alternative Name" - also sometimes called "Unified Communications Certificates" after a feature in Microsoft Exchange Server which requires this certificate type. These certificates declare a finite list of hostnames they can be used against.
Then there's wildcard certificates. Historically these were very expensive but recently we've seen a huge drop in price. With one of these certs you can secure anysubdomain.mydomain.example including the top-level mydomain.example.
Without either of these SSL certificates you'll need to get an SSL cert for each domain name you want to secure.
Note that having a different certificate for each hostname/domain-name can cause problems because the TLS system establishes security for the channel before the HTTP Host: header is sent - this means that each secured website will need its own IP address or port number.
...unless you use SNI (Server Name Identification) certificates. The good news is that all modern browsers and servers support it SNI, so multiple secure websites can share IP addresses and port bindings with their own certificates (so without needing a single SAN certificate that lists all domains on it).
The bad news is that Internet Explorer on Windows XP cannot connect to SNI websites (but Chrome and Firefox are okay), and on the server-side you need at least Windows Server 2012 or later. So adopt SNI based on how popular IE+XP usage is.
Related
This question already has answers here:
Is a self-signed certificate secure enough?
(3 answers)
When is it acceptable to use self-sign cert in production?
(2 answers)
Closed 1 year ago.
I am attempting to securely communicate between two embedded devices.
One (referred to as the server) is acting as a WiFi access point, similar to a router. It runs a HTTP server at a constant IP address. My goal is to enable SSL on this server.
The other (referred to as the client) connects to the server's WiFi access point and makes request to the HTTP server in order to provide the server with information it needs to operate.
Every example I can find that attempt this uses self-signed certificates. From my (limited) understanding of TLS, these are not secure and should only be used for development.
I believe what I want is a trusted certificate. However, every example I can find generates these certificates for websites. I am struggling to understand:
If it is possible to generate trusted certificates for this application, and
How to do so.
Any help is appreciated!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I have a site that is active/online, that have an SSL certificate.
Can I use the same certificate, on a development site, that is also online, that can be access by ip ?
On the development site I'm using Linux/NGINX.
More info:
The development site will not use the same hosting/technologies when will be active as the current website
I want other people besides the development to access the development website
Because the domain will remain the same, and the SSL is on the domain, I wanted to set the correct SSL on dev to prepare to replace the other website
The dev server is on a public VPS
Taking from answers, please explain: the development website must work if called by the same name that your current site is ?
I'm confuse, When I type the domain name will always trigger the active website(both are public).
A certificate is valid for a name, not for an IP address.
You can use the same certificate, as long as you can reach the other site by the same name. If this just refers to your development machine or a group of developers, you can edit the hosts file or have a DNS server resolve the name to the IP address of your development site. The question is whether this is worth the effort. If the number of developers is small, it is easier to tell them to just accept the certificate.
If you want other people to access the development site, such as for beta testing, just get a DNS name and a certificate for the development site. Use a Let's Encrypt certificate, it's free.
Edit
It doesn't matter for the certificate whether the development site uses the same technologies as the active website.
As stated, a certificate is valid for a name, not for an IP address. You need a DNS name and a certificate for the development site.
If "domain will remain the same" means that you have a wildcard certificate, as in *.example.com, then it will work for both www.example.com and dev.example.com. However, if your certificate is for www.example.com, then it will not work for dev.example.com just because part of the name is the same.
It doesn't matter where your dev and production server are.
Yes you can use the same certificate if some conditions matches:
the developement website must work if called by the same name that your current site is
you need to somehow have this site name resolve to the development ip address (either by modifying a hosts file, or by using a custom DNS server)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have a commercial SSL Certificate for my website, say https://www.xyz.com
The SSL is configured in apache-vhosts.config (Apache virtual host port 443)
I am planning to introduce sub-domains like:
http://apples.xyz.com
http://oranges.xyz.com
http://mangoes.xyz.com
These will all be configured as Virtual Hosts in Apache Config.
Question:
Do i need to buy separate SSL Certificates for each of these sub-domains, or will my existing commercial SSL Certificate work?
This depends on the type of SSL certificate you purchased. If you bought a wildcard SSL certificate, or one that explicitly has subdomains in it, you're probably good to go. If you bought a cert that only has www.xyz.com defined, then you're not going to be able to use the same cert for the different subdomains.
If you bought for only the www subdomain, then depending on your server topology, you could either buy a cert for each subdomain, and use different IP for each subdomain (or if you don't care about older browsers, use Server Name Indication).
My recommendation if you bought a single domain SSL cert, and you're going to have many subdomains, just to bite the bullet and buy a wildcard certificate.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 months ago.
Improve this question
I'm wanting to cover the a few domains with an SSL Certificate.
e.g.
portal.domain.com
app.domain.com
app1.domain.com
app2.domain.com
I'm a bit confused as to whether I can go for the cheaper Unified Communications Certificate, or whether I need to fork out for a wildcard certificate.
Is the only difference that the wildcard can have an unlimited number of subdomains, where the UCC only covers a set number under the SANs?
Thanks in advance
Yes, you are right Unified Communications Certificate covers a set on SANs but it can secure multiple domains, and hosts configured in your Exchange server where a traditional wildcard SSL cannot. For e.g. A wildcard ssl can secure first level of sub-domains like *.example dot com where a Unified Communications Certificate secures www.example dot com, www.example dot net etc.
Yes. Keep in mind that some old X.509 implementations might not support SAN, but that's pretty rare today (some Symbian OS phones for example, see http://www.digicert.com/subject-alternative-name-compatibility.htm).
Generally, a domain name or URL requires just one certificate to be secure. But what if you need to secure multiple domains? How can you manage their security without sacrificing budget and time?
Securing Multiple Domains
Securing multiple domains can be achieved with 2 approaches, Wildcard certificates and Unified Communications Certificates (UCC), also known as SAN (Subject Alternative Name). SAN lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single SSL Certificate, while a Wildcard certificate can support a single domain and an unlimited number of first-level subdomains. SAN/UCC can also be combined as an extension with a Wildcard to add functionality to the certificate. You can combine these two certificates as a Multi-domain Wildcard SSL Certificate depending on your needs. This makes managing the security of multiple websites much easier and cheaper than managing a separate SSL certificate for every domain you own.
Read More: Wildcard Vs SAN/UCC Certificates
It's only cheaper up until a certain number of domains, because UC and SAN certs charge by each domain name. You'll notice the price changes as you enter and subtract domains from this UCC link
If you know that you will have more than say 5 subdomains, save some cash with the wildcard because it's a set prices regardless of the number of sub domains.
UCC and SAN is only recommended for exchange server. your requirement seems like you need ssl with common name *.domain.com so that single ssl works for all sub-domains.
Know what exactly UCC and SAN is..
UCC / SAN cert is recommended only if you need to secure different tld like urdomain.com urdomain.co.uk urmydomain.net. This kind certs cost too much as it starts from $200.
Answering your question, I checked few brands wildcard ssl RapidSSL wildcard, comodo positive ssl wildcard, globalsign alphassl wildcard, geotrust wildcard ssl. I tested these brands installed ssl website in my iPhone and Samsung android phone. All works perfect.
I reviewed many ssl providers for UC certificates pricing. Apart from the pricing, I found some ssl providers sell same product with different names, like multi-domains ssl, san certificate and uc certificates.
Microsoft exchange server requires typical UC certificate, strongly recommended by Microsoft. I decided to purchase UC certificate but it costs too much, starts from $300 to $600 with veriour providers like comodo, globalsign, digicerts etc. First I purchase single domain ssl and failed in exchange server installation. I thought could save $$$ with single domain ssl.
Later I searched for UC certificate prices $50 to $100 and found ssl2buy ssl company provides comodo uc certificates for $60 only and it includes 4 domains.
https://www.ssl2buy.com/comodo-multi-domain-ssl.php
I purchased this uc certificate and installed on my exchange server. It works fine! No error - No installation issue, nothing.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a WCF service hosted under IIS 6.0 running under Windows 2003 R2. The service is SSL secured with "Required client certificates" option.
When I browse the service from IE within win 2003 R2, I am able to see the WSDL.
When I try to browse from my development machine running IE on Win XP. I see 403.7 error like this.
The page requires a client certificate
......
......
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I have spent 5 days on it tried everything possible like
Checking the client certificate on Client, private key, importing it again and again.
Checking its intended purpose (client Authentication) and EKU value.
Checking the CA is installed on both server and client in Trust Root Cert Authority Folder.
Running SSL Diag tool. Unfortunately it shows the message which i pasted above and not much detail.
It works when I try the option "Accept Client certificates" under IIS Directory security tab.
Is there something that I am missing or unaware of it?
Finally with the help of MSFT support, I have resolved it.
The reason was, on the webserver there were too many certificates in the Trusted Root Certificates Authority folder that it exceeds the recommended length. Hence i got this warning in eventlog.
When asking for client authentication, this server sends a list of
trusted certificate authorities to the client. The client uses this
list to choose a client certificate that is trusted by the server.
Currently, this server trusts so many certificate authorities that the
list has grown too long. This list has thus been truncated. The
administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that
do not really need to be trusted.
I did delete some the the expired/unused certificates but still it wasn't sufficient. I couldn't delete more certificates due to fear of breaking the system because they were not expired.
We used method 3 to fix the problem which is discussed here
Though it had fixed my problem but only draw back of using this method is, client browser will present you the list of all client certificates present in the computer instead of choosing which one server wants based on the Trust Root CA.
This works for me because I have a WCF service and not a website.