I am putting a web test up for clients that visit "https://oursite.com/poodlesecurityfailed.js"
Question,
Do I need a valid certificate even though its on a test domain for certificate negotiation? If client can visit it, they failed the poodle test. (SSLv3 is enabled) on that host.
Ideas?
Do I need a valid certificate even though its on a test domain for certificate negotiation? If client can visit it, they failed the poodle test. (SSLv3 is enabled) on that host.
Depends on the client.
If the clients is has enough knowledge to understand, that "invalid certificate" when accessing the site means in reality that the client has still SSL 3.0 enabled, then a self-signed certificate would be enough.
If you instead want to provide an explanation of the problem at this site and don't expect the client to explicitly accept an invalid certificate just to see this explanation, then you should better use a properly trusted certificate.
Related
Can someone kindly help me understand the following and suggest a possible fix?
Problem: Secure websocket (wss) connection fails in Chrome browser, when using a multi domain (SAN) SSL certificate
Details: We have a multi domain SSL SAN certificate that covers, say, webapp.example.com and websocket.example.com. The page https://webapp.example.com/ loads correctly (the domain is verified correctly against the SAN certificate by the browser, and a 'lock' icon is shown to indicate that the connection is secure). However, the said web application on that page also attempts to makes a connection to wss://websocket.example.com/. This connection is failing with ERR_CERT_COMMON_NAME_INVALID.
A weak hypothesis for the failure: This error is possibly because
The browser first opens an SSL connection to https://webapp.example.com after verifying webapp.example.com as a valid domain in the SAN certificate
When a connection is made to wss://websocket.example.com, the name 'websocket.example.com' does not match with the domain that has been previously verified (webapp.example.com).
Question: Is it possible to make this work? If yes, how?
Your hypothesis is wrong. The certificate validation is always done against the domain in the currently accessed URL. It is not done based on some URL previously accessed, even if the provided certificate was the same.
It is more likely that the domain you access is actually not contained in the multi-domain certificate. Note that an entry of webapp.example.com or example.com in the certificate does not cover websocket.example.com or similar in the URL.
I've always been an end consumer of HTTPS and have never really understood it that well but am looking to change that.
I am calling a RESTful web service over HTTPS. For example...
curl -X GET \
https://myCompanydns/rest/connect/v1.4/myEndpoint
With all my requests I send a basic authentication header i.e a username and password.
When I make these calls via my application I was expecting to have to add a certificate into like a jks (which I've had to do in the past) but on this occasion I've found that I can call the HTTPS web service without that.
For HTTPS to work I believe there is an SSL handshake? How is that happening successfully is this scenario without a jks?
Again, sorry for this beginner type question.
When doing a https://... request the client needs to verify that the servers certificate is the expected one - and not some man in the middle. This is done (among other things) by making sure that the servers certificate was issued by a trusted certificate authority (CA). Which CA is trusted is setup in the local trust store (i.e. local to the client). In the above call where no explicit trust store is given curl is using its default trust store. In the case where you've explicitly gave a jks you've provided the application with a specific trust store it should use.
For more on how the server certificates gets validated see SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate?.
I purchased a domain name. I set up a website that is deployed on Apache, that is accessible at my domain, currently on http protocol "port 80". I now want to configure this Apache server for SSL. I'm evaluating the below 2 options.
Option #1: I create the "Certificate Signing Request" (CSR), then while acting as the CA, I create the certificate based on the CSR, I then configure Apache to be running on port 443, with the certificate I created.
Option #2: I create the CSR, I submit my CSR to a widely known CA like Symantec to get a certificate. I then configure Apache to be running on port 443, with the certificate provided by Symantec.
What are the downfalls to option #1?
From an end-user perspective "someone accessing my site", what indications would they have that I used option #1?
Is it correct to assume, with option #1, that I couldn't get end-users accessing my site to get a green bar menu?
With option 1 the end user has no confidence they are not being spoofed. Because you are acting as your own CA the end user has to make a decision about whether to trust you. If they do - they may well be trusting someone who has intercepted your request and used their own certificate.
With option 2 the user is trusting the CA that provided your certificate and can be more confident that no man-in-the-middle attack is taking place.
For some purposes your own self-signed cert can be fine. Not for any real ecommerce though.
I am testing a web service with an external partner using 2 way SSL under IIS 7.5. I am requiring SSL, requiring a client cert, and using one to one mapping to authenticate to a domain account. I have configured everything and it works fine on our network (I am able to provide a client cert, get authenticated and invoke the service from browser and test harness).
From outside of our network (in most cases, see below), I am getting a 403.7 error. I have gone through the machine level certificate store and made sure the certificates and CAs are trusted.
Here's the weird thing. I obtained a Type I cert to test from home (and got 403.7 like our intended partner is). So I setup Fiddler to debug SSL and send my certificate, and this works for some reason. I setup a test harness to pass the exact same certificate, and got 403.7. I test in my browser (IE 9), don't get a prompt for a client cert, and get 403.7.
Any help appreciated.
Bill
Last time I checked, IIS was using re-negotiation (by default) to get the client certificate: there is a first handshake where the server doesn't request a client certificate, followed by another handshake (encrypted this time) where the server requests the certificate (via a TLS CertificateRequest message). This will prevent you from seeing anything from Wireshark, unless you configure it to use the server's private key and decipher the traffic (note that this only works with some cipher suites).
One way to see the client-certificate negotiation is to configure IIS to use initial client certificate negotiation, using netsh and clientcertnegotiation=true (which is about initial negotiation). At least the CertificateRequest and the certificate will be sent in clear during the handshake, so you should be able to see this with Wireshark.
If the client isn't sending a certificate to the server as a response to the CertificateRequest, you'll still see an empty Certificate message from the client.
If you don't export the private key with the certificate to use with Fiddler or whichever other client, there is no chance that it will be able to use the certificate. It may at best try to send the certificate, but the handshake will fail (since the CertificateVerify message needs to be signed by the client's private key).
I guess you may encounter a problem whereby:
not presenting a certificate is accepted by the server (it's effectively optional),
presenting an invalid certificate makes it fail and causes this 403.7 status code (many servers and SSL/TLS stacks would implement this as a fatal error, but TLS specification doesn't say that unsupported_certificate, certificate_revoked, certificate_expired, certificate_unknown should be fatal, so this is at the server's discretion).
Are you using the same physical machine to test both the in-network and external-network connections? If not, are you sure that the external-network client has the private key accessible?
I have not configured Fiddler client authentication before. Does it read the client certificate and key from the standard certificate stores? Does it read directly from a PKCS12?
One other thing that may be helpful is inspecting the TLS handshake in WireShark. Specifically, check out the Server's "Certificate Request" message, as the data here clues the client (IE9) which client certificates it should display in the prompt. Compare this for the internal and external connections.
I got an issue from my client regarding the SSL setup for his website. I'm not familiar with the SSL certification setup process. He is saying that We have an SSL certificate for this server but I can’t tell if it’s setup properly or not.
If I open that website, firefox says Warning: Contains unauthorized content. I am seeing some details in the warning message window which are given below:
Web site: mydomain.com
Owner: This web site does not supply ownership information
Verified by: Not specified
Mainly I want to know whether the SSL certificate used for this site is valid or not. Can anybody suggest a way to check for the SSL certificate validation of a website.
Thanks
Telnet the server on port 443. If it is responding then it is a certificate problem
To install certificate
Check this