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.
Related
So we have some software that when installed runs a web app on iis at localhost on the users machine..
In order to use ssl we provide the user with a self signed certificate.. which results in an error like this when opened on chrome on the users machine..
I'm assuming this is because we are using a self signed certificate..
Now I noticed if I set the sites certificate to IIS Express Development Certificate the error went away.. and the site loaded normally on chrome..
So what I'm wondering is if I can install the software that runs the web app on the users machine. THEN can I programmatically set the web sites certificate to IIS's "IIS Express Development Certificate"?
Is this ok to do?
It to OK to share a self-signed certificate with your customers, but that's really not the best practice. For example, if the machine is compromised and the self-signed certificate is replaced by another one generated by the hacker, the customer usually won't notice the difference but the hacker can gain more access (and perform more damage).
Instead, allow your customers to use their own certificates and that's quite common in real world, as many customers have their own AD and CA configured already. They can issue their own certificates for clients/servers.
If you insist using self-signed certificates, ask your customers to trust such manually, for Edge/Chrome,
https://docs.jexusmanager.com/tutorials/self-signed.html#to-trust-self-signed-certificate
Firefox needs another procedure.
IIS Express Development Certificate should trigger the same warning by default, but this specific customer might have already trusted it on this machine. However, you cannot assume such applies to all your customer machines.
So, I have a wildcard SSL cert from Go Daddy, and it has been installed on a few servers. However, on one particular server I cannot seem to get this thing done. Here's the process that has worked on all servers but this one:
1. Create CSR
2. Having gotten the certificate from the provider, I open the MMC certificates snap-in and import the intermediate cert to the intermediate authority store (or personal store, both have been tried). This is successful, in that I can view the certificate from the MMC
3. Go to the IIS server and under Server Certificates, I complete the CSR, point to the provided certificate and it imports into the web server successfully.
4. I go to an individual web site to assign the certificate to the web site under binding. When I select https and the IP address, the drop-down menu activates, but the certificate I just installed is not available for choosing.
5. I go back to the server Certificates, and the cert I just viewed is no longer there.
Go Daddy says to rekey, however, this makes no sense, since immediately prior to this, I installed that same wildcard cert to a different server, and it works fine. Obviously, this is something with IIS or Windows on this particular server.
Does anyone have any idea how to fix this without rekeying? Server platform is Windows 2008R2, IIS 7.5
If you have followed steps described in https://www.godaddy.com/help/iis-7-install-a-certificate-4801 then from your side it's done. And for more references, you can also check out this https://stackoverflow.com/a/43247419/7738413
Otherwise, rekeying is the last option.
I want to move my MVC application from Azure to an in-house server. How do I export the SSL certificate associated with the App to install it on the local server?
Is it at all possible?
NO. There is no way to get certificate out of Windows Azure. Question is how it (the certificate) appeared in the Azure at first place. It was certainly not uploaded by Microsoft people or some magic. It is a developer who packed the deployment package to include the certificate reference (thumbprint) and service administrator (or co-admin) who uploaded the original certificate in the Azure. So contact that people (whom might be just you?) and ask for the original certificate.
If certificate is lost, contact the original issuer (certification authority) for a copy, if you were the one to originally requested. If you did not originally requested the certificate, there might have been a reason behind that.
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.
For some of my site visitors, the SSL certificate is failing. Whatever tests I do on various browsers for me the SSL certificate is valid.
I can't think of how to test this on client side, and to identify the problem.
How would you do this?
One client gets: fatal certificate unknown
While RouMao's answer is mostly correct, he has missed what is (IME) the most common problem with SSL certificates - the certificate you are using requires an interim certificate from the CA which you have not included in your certificate chain. Most CAs provide an online tool for analysing the certificate - try the one located here.
Also, is there any correlation with which browser being used? Notably, Chrome does not handle SSL v2 by default
Most of the failing of SSL certificates were caused by visitors themselves. Somehow could not tests or verified by server implementation.
Here are some obvious examples:
Your cert is validated since April 1st 2012, but the client's local machine time is set to 2010 -- one year later than current time. In this case, the visitor should encounter problem all the times, until his machine time is later than April 1st 2012.
visitor is behind a restricted firewall. The firewall could terminate the SSL/TLS connection and re-crypt the link with a pseudo/self-sign certificate. Indeed this could be considered as a man-in-middle attach.
The Trusted Root Certification was removed by client himself
it is very hard to fix all these problem. Sometimes, you need to create a client side native application to detect or fix all the possible problems, and require client browser to execute the application each time before it enter the HTTPS mode.
P.S. most of the e-bank application do like this.