I installed a FreeRADIUS server for 802.1x authentication: it works when I configure the supplicant in EAP-TLS mode using a client certificate.
But when I configure the supplicant to verify the server certificate, it doesn't work.
What could be the problem?
When the supplicant is not authenticated, how can it verify the server's certificate since it does not have access to the network and therefore to the CA .... Couldn't the problem come from there?
Related
I have this weirdest problem. First off: I'm VERY new to this certificate thingy. I've done a fair amount of searches and reading up though.
The CA Cert that I install into the Trusted Root Certificate
Authorities store in my server automatically get removed/disappeared
as soon as a client web-browser try to connect to a web-site using an
SSL cert created with that CA cert.
DETAILS:
Windows Server 2008 R2 (development server).
I've created my own Certificate Authority Cert; which I use it to generate an SSL server cert (to install on my IIS 7 Server) and a client cert (for use at my local PC to connect to the WCF Webservice on the development server which is set to Require SSL and Require Client Cert).
I installed the CA Cert into the Trusted Root on both Server and local PC.
Installed the SSL server cert into the IIS7 for that particular site and did the https binding to port 443.
As soon as I launch my browser to access that site with HTTPS, the CA
cert in automatically removed on the server (from the Trusted Root
Certificate Authorities store). and my local PC browser will report
an error 403.
This is driving me nuts... anyone knows what is happening?
Apparently, after a lot of running around, it is due to too many of the same certs in many stores.
I open the MMC.exe > Add/Remove SnapIns > Certificates
Notice there are 3 types there (My User Account, Service Account & Computer Account).
Open up My User and Computer Account, go through all the stores for each one and DELETE all of the CA cert with the same name. Then add the CA cert in either My User Account or Computer Account, depending on how you access the certs (in the event of the cert being used programatically, install it in the Computer Account, [Trusted Root Certificate Authorities].
Just 1 place, then the problem will dissappear.
In order to secure my Rest Services, I have enabled SSL in IIS and Created a Self-Signed Certificate and assigned it to the HTTPS binding in IIS. I exported the same as pfx file and added the same in IE also but when I try to access the Services, I get the following error on Windows 7, Enterprise edition
HTTP Error 403.7 - Forbidden
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) client certificate that the Web server recognizes.
And on Windows Server 2003, this is
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I am not sure what shall I do except adding the certificate in IE under “Personal” and “Trusted Root Certification Authorities”? Could you please suggest me some step, in order to make this work.
Note: I have tried with “Self-Signed Certificates” as well as with Certificates generated from Microsoft “Certificate Services” also.
Any help is greatly appreciated.
SSL is used to verify the identity of the server, not the identity of the client. The error suggests (http://support.microsoft.com/kb/199215, "This is used for authenticating you as a valid user of the resource. ") the server wants to identify the client. Which of the two are you trying to do?
Edit: SSL requires the public part of the SSL certificate to be available to the client. Adding it to the trusted root certificates seems to me to be the only way to make the public part of a self-signed certificate available to the browser.
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.
Just got my Lync server deployed on Windows Server 2008 R2 and am trying to connect via Lync client on a different machine. When attempting to sign in, the client throws an error saying "Cannot sign in to Lync: There was a problem verifying the certificate from the server.".
Looking deeper, into the client box's event viewer, I see the following error "The certificate received from the remote serer was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The SSL connection request has failed. The attached data contains the server certificate. ....
My organization has an internal CA, which is in charge of issuing all required certificates to the Lync server. My client box has installed the internal CA (root) as a trusted CA provider. To me, this should cause any certificates that issues, including the Lync certificates, to be trusted.
I installed Lync client on the same box that Lync server is hoted, and am able to log in fine. My error only occurs when connecting from a different box.
Can anyone shed some light? Thanks!
I had same issue. To resolve: from client, hit url of CA Authority, some thing like http://CAservername/certsrv this provided option to download a CA Certificate Chain.
Put this into local computer trusted root certs and I was good to go.
As mentioned in the error message ("Cannot sign in to Lync: There was a problem verifying the certificate from the server"), this is clearly a certification error. If you work in a big company (where they have they own internal CA - (Certification Authority)) in most cases they would have used their internal certificate to establish trust relationship. If you just install/export the Root certificate of the CA under "Trusted Root Certificate Authorities” of “Local Computer” account, this error should be resolved.
If your company doesn't have own CA, then find our who issued the certificate for Lynch and install/export the root certificate of that CA to the same location as above, this issue should be resolved.
I've godaddy's 2048bit certificate for domain and 4 subdomains.
[www.site.com, mail.site.com, e.t.c.]
Standard Multiple Domain (UCC) SSL Up to 5 Domains - 1 year (annual)
That certificate works fine in Apache, ssl web checker says OK and browser shows green line in address string.
I've added this certificate to mail daemon, it has been accepted by Exim too.
When some client tries to send mail with SSL/TLS connection through mail server, mail program says "Certificate is BAD" though shows correct trusted info.
Client connects to hostname: mail.server.com, server's hostname is: ns1.server.com (not added to certificate), mail server says: 220 ns1.site.com ESMTP Exim 4.73
Mail clients tested: iPAD mail client, Mozilla Thunderbird, Mac mail client
Please help.
UPDATE:
Godaddy's ssl checker says: SSL Chain of Trust is Broken!
Here are a couple of things to check:
Is the hostname that the mail client uses in the TCP connect, listed in the server certificate as the Common Name (CN) of the subject distinguished name?
If not, is it listed using type "DNS:" in the Subject Alternative Name X509 v3 certificate extension?
If neither of the above, you might be getting "Remote Certificate Name Mismatch" (or similarly named error.)
If it is listed, then look for the Issuer of the certificate, and Issuer of the Issuer, etc., all the way to the root certificate of the chain. The root certificate should be installed on the client machine, in the "Trusted Root" certificate store for whatever client you are using (Windows, Mozilla, Java keystore, etc.)
If the root certificate is installed, then look at the intermediate certificates, if there are any in the chain (between root and server certificates). They have to either be installed locally, or arrive from the server alongside the server certificate -- either the server sends them each time or you've got the intermediate certificates already installed on the client end. Either way, they have got to be in hand to accept the server certificate.
Do the clients which reject the certificate have the appropriate root certificates in their cert store?