I have purchased & installed Godaddy SSL certificate. When I access the site using Chrome 24ver the https padlock shows
1) encrypted with 128-bit
2) uses TLS 1.0
3) encrypted using RC4_128 with SHA1
However I read that RC4 is not safe anymore. So my question is
1) How reliable is https connection with mentioned specs
2) How do I get AES_CBC certificate?
3) I was being told that since the server is windows hosted it cannot be upgraded to 256-bit. Is it true? If not then what should I do?
Thanks
You are mixing things up. There is no RC4 certificate or AES_CBC certificate.
You certificate is signed by a certificate authority that issued it. In your case it is Godaddy. Look for Signature Algorithm property when you open details of the certificate (i.e. doubleclick on certificate file). There will probably be something like sha1RSA or sha256RSA or something similar.
RC4 is a cipher that is negotiated when establishing SSL conection with server. It depends on both parties (client and server) witch algorithm they will use. Read more here. You can set up IIS to allow or disallow these ciphers.
Related
I secure successfully a Nifi Node (localhost) with SSL but I have always a yellow padlock in my browser as you can see in the pic here
Do you have any idea?
Thanks
If you used an untrusted certificate then this is expected behavior. You would have to purchase a real certificate for a real domain name in order for the browser to not warn you.
I see the description below:
Standalone : generates the certificate authority, keystores, truststores, and nifi.properties files in one command
Client/Server mode : uses a Certificate Authority Server that accepts Certificate Signing Requests from clients, signs them, and sends the resulting certificates back. Both client and server validate the other’s identity through a shared secret.
Standalone and client, both generate the certificate authority, keystores, truststores.
Sorry, I don't see the difference.
I'm wondering why we need SSL certificate ? Because the moment we generate the keystore, it does the same functionality. It gives SSL platform.
May I know please why we need certificate and if it really needs then how it works (Certificate merged with keystore) when a third party sends a request to access web-server's website ?
To use the SSL certificate in a web server, you configure your web server software (Apache, NGINX, etc...) to read the certificate. Tutorials on this topic abound; here is a sample set of instructions from DigiCert, who sells SSL certificates: https://www.digicert.com/ssl-certificate-installation-ubuntu-server-with-apache2.htm
I'm trying to set up client certificate authentication. I was able to generate a CA-, server- and client-certificate. As long as I use Fiddler everything works as expected. However, as soon as I start using a browser it doesn't work anymore (HTTP Error 403.7 - Forbidden).
Of course I imported the client certificate in the Personal store and I made sure Client Certificate Negotiation is enabled.
I also tried openssl s_client -connect 127.0.0.1:443 -state -debug but I couldn't really make sense of the result... The only thing what's weird is that my CA doesn't show up in the Acceptable client certificate CA names section.
Anything else I could try?
Update:
I think it doesn't matter but my server certificate is set up for 127.0.0.1. Therefore I'm using https://127.0.0.1/... in my browsers.
Update2:
Using Wireshark I noticed that my servers' response depends on the client:
Fiddler (OK):
Client Hello
Server Hello, Certificate, Server Hello Done
Browser (Not OK):
Client Hello
Server Hello, Change Cipher Spec, Encrypted Handshake Message
Update3:
After enabling clientcertnegotiation the server response is different but still doesn't work:
Server Hello, Certificate
Certificate Request
Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
My self-signed CA doesn't seem to be in the Distinguished Names list...
Update4:
SSL Settings: Checked Require SSL and Client certificates set as Required. Client cert shows up in Personal and the intended purpose is Client Authentication.
I finally found the issue and a workaround:
As mentioned in Update3, Distinguished Names doesn't contain my CA. This is because Distinguished Names has a limit of 2^14 bytes (16384 bytes). Because I do have a lot of CA installed on my machine my CA simply didn't make it in. The TLS standard would allow to send multiple messages but unfortunately Windows doesn't support this!
As mentioned here you have a few possibilities. The simplest one is this:
At your server add a DWORD (not QWORD!) value called SendTrustedIssuerList in your registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL and set it to 0. This will prevent your server from sending a list at all, letting the client choose from any installed client certificate.
Unfortunately I couldn't see any traces in the Event Viewer (as reported elsewhere). Therefore the issue wasn't easy to spot (I had to use Wireshark in order to check Distinguished Names).
Use the Accept option instead of the Require option of the "Client certificates" feature.
In IIS Manager, locate the Web application for which you want to change the SSL setting.
In Features View, double-click SSL Settings.
On the SSL Settings page, select the Accept option under Client certificates.
In the Actions pane, click Apply.
More info here
Client certificate should be imported in CurrentUser\My store with private key (i.e. p12 or pfx file usually).
CA certificate should be in LocalMachine\Root store so that IIS trusts all certificates issued by the CA and the CA is trusted for every user on the computer.
CRL issued by the CA should be either available through URL (specified in every end entity certificate that CA issued) or imported in LocalMachine\My store.
NOTE: openssl doesn't use windows certificate store so this will have no efect on openssl s_client -connect 127.0.0.1:443 -state
I'm trying to create web application with client certificates, generated programmatically. My main problem is following: I've added generated .p12 keystore to my web browser, but it doesn't send certificate to the server.
How does browser understand which x509 certificate it should use? And is it possible to debug SSL in Chrome of Firefox?
SSL/TLS server sends Certificate Request message (see RFC 4346 for TLS 1.1 or others). In this message there is only certificate type and acceptable certificate authorities names, so server doesn't tell anything about particular certificate.
The possible reason is that your certificate of invalid type (i.e. DSA instead of RSA but key exchange algorithm depends on client RSA certificate), or server requests certificate of different certificate authority.
I have a server with an SSL certificate and clients with SSL cetificates, all are signed by the same CA, and the CA is trusted on the server and clients as a root authority.
However none of the clients I have tried (iphone, chrome, explorer) will send the client certificate when the server requests it, even though they all verify the server certificate fine. They all claim not to have the certificate.
When I look at the client certificate in the certificate/profile/store they all claim it is verified and legit, and all the certificates verify fine using openssl etc.
Does an SSL client certificate need a specific name or other details so that client browsers will know when to use it? Kinda of like how a server certificate has to specify the exact domain as the name on the certificate?
The server is an apache2.2 server, but I don't think its a problem on the servers end.
Client certificates must have appropriate Key Usage and Extended Key Usage extensions set. What is "appropriate" in your case, I don't know for sure but the number of variants in Key Usage is small and you can check various values yourself.
You surely haven't forgot about the private key which should be accessible on the client side, have you?
There's a summary of the key usage and extended key usage extensions to use in this document:
http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html
(Although it is for NSS, it should apply to other products.)
You could also check whether the list of accepted CAs sent by the server is configured properly. This can be seen using openssl s_client -connect the.host.name:443, for example.