I set up the Keycloak 4.8.2-Final on my localhost and enabled the SSL as described in the document on https://www.keycloak.org/docs/latest/server_admin/index.html#_x509.
The server could start but I could not open the server page on the localhost:8443
openssl s_client -connect 127.0.0.1:8443
due to the SSL error code 42
4566025836:error:1401E412:SSL routines:CONNECT_CR_FINISHED:sslv3 alert bad certificate:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL alert number 42), which means that the client certificate problem.
But my imagination was that the server should redirect me to the login page. After I logged in, the server should generate the client certificate and ask me to download the certification and import it to my browser. After that I should be able to connect to the server without any further authentication, because I already had the client certificate trusted by the Keycloak.
What did I do wrong? Or this process is not supported by the current keycloak yet?
According to the document it is not support to download and import the certificate after user input the user name and password. The first two steps are always:
A client sends an authentication request over SSL/TLS channel
During SSL/TLS handshake, the server and the client exchange their x.509/v3 certificates
Therefore the configuration in the standalone.xml shall only be "REQUESTED". Without a real understanding I changed it to"REQUIRED" which asks always for client certificate. If the client does not have that, it fails. With "REQUESTED" the client certificate is just optional.
<subsystem xmlns="urn:jboss:domain:undertow:4.0">
....
<server name="default-server">
<https-listener name="default"
socket-binding="https"
security-realm="ssl-realm"
verify-client="REQUESTED"/>
</server>
</subsystem>
Related
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?
On Windows 7Pro, I have a secure socket client app using schannel.
Connecting to a secure server with TLSV1.0, 1.1 and 1.2, without client authentication works fine.
Connecting to a secure server with TLSV1.0, 1.1, with client authentication works fine.
A connection with client authentication with TLSV1.2 fails. Instead of replying with handshake certificate, the client replies with 3 TLS records: Client Key exchange-Cipher change spec-Client key exchange. As the server does not receive the client's certificate, it aborts the connection.
The client's certificate has an intermediate and trusted root ca. In all cases AcquireCredentialsHandle is called with
SCH_CRED_NO_DEFAULT_CREDS|SCH_CRED_MANUAL_CRED_VALIDATION|SCH_CRED_NO_SERVERNAME_CHECK,
and InitializeSecurityContext with (among others)
ISC_REQ_MANUAL_CRED_VALIDATION and ISC_REQ_USE_SUPPLIED_CREDS.
Do I need to treat client authentication differently for TLS V1.2?
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.
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?