I am trying to understand TLS. I captured communication from browser to various sites. I tried to google but could not find anything that clarifies why in some of the captures I have 'Certificate Status' except of 'Certificate' in a reply from the server.
Please have a look at the screenshot to get a better understanding to what I exactly refer to.
In short my question is - why sometimes some servers reply not only with a certificate but also certificate status and the others only with a certificate?
[on the screenshot are communications with 3 different sites. 2 of them with certificate status, 1 without certificate status - Please focus on marked with the red color parts of communication]
https://i.stack.imgur.com/7Ezpw.png
[I find status_request extension in all communications, but not everywhere it is answered with Certificate status:]
https://i.stack.imgur.com/Dxp4b.png
You may want to check the client's TLS extensions to see if the client requested OCSP status from the server. You'd find more details on the extension in this RFC: https://www.rfc-editor.org/rfc/rfc6066
Related
I'm getting errors, such as the one below, in my /var/log/mail.log file.
Apr 9 18:28:29 blueberry postfix/smtps/smtpd[13294]: warning: TLS library problem: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired:../ssl/record/rec_layer_s3.c:1544:SSL alert number 45:
I'm 100% sure the certificates are valid since I'm using them on my websites, all of which couldn't be happier with them. Postfix was also happy previously, but since I renewed the certificates it's been spamming this when my Nextcloud server tries to (and can't) connect to the mail server, despite my mail client still working (although without rDNS as I didn't manage to get my provider to set it up).
I assume the blame is somewhere with Nextcloud - presumably the php handler for mail. Another thing that could be at fault that I tried to check is OpenSSL, but I have no idea how to replace its certificates with my own (generated by Acme.sh).
Both dovecot and postfix have in their config mentioned the correct path to my keys, hence the assumption above.
EDIT: Fixed it.
So, turns out, when I updated my certificate locations when I changed the method of acquiring them (certbot vs acme.sh), I got a typo in one of the filenames. /etc/dovecot/conf.d/10-ssl.conf was correct and so was /etc/postfix/main.cf, but /etc/postfix/vmail_ssl.map had a typo which I didn't see previously - and so was throwing a certificate error.
I tried posting this on ask.openstack but it has been stuck in the moderator for 5 days now. I thought I'd try here.
I was trying to debug a Nova issue and wanted to decode the SSL / TLS packets being exchanged using Wireshark. Part of the changes I was making was setting Nova up to use SSL / TLS and I wanted to be sure that part of it I had set correctly. I eventually figure out my issues from the various log files but I'm somewhat assuming that being able to watch the network traffic may help in some very difficult cases.
The exchange uses TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 at one point. According to this security stackexchannge question, there is a "pre-master secret" or various other terms. I've wrestled with this before in a previous life doing IPSec. Usually you can set debug in the application and it will spew out the secret into the log file. I tried "debug = true" under Default in nova.conf and got lots of debug but no secret. There was two items that looked interesting that were reported as **** in the log: keystone_authtoken.memcache_secret_key and neutron.metadata_proxy_shared_secret. I wasn't sure if those were the secrets I was looking for or not. In this case, I'm looking at the nova-api traffic going to port 8774.
Also, since all of openstack is Python and uses the same "request" and "certifi" packages, it may be possible to generalize this to all of the openstack components.
nova --version report 9.1.1
We're struggling to get IBM MQ to work across SSL.
We've been provided with the certificate chain for the remote host and installed into the Windows Certificate Store (Local Machine). These all look valid.
We're using the following connection properties:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "other-server.com");
connectionProperties.Add(MQC.SSL_CIPHER_SUITE_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256"); connectionProperties.Add(MQC.SSL_CIPHER_SPEC_PROPERTY, "TLS_RSA_WITH_AES_256_CBC_SHA256");
connectionProperties.Add(MQC.SSL_CERT_STORE_PROPERTY, "*SYSTEM");
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmywindowsusernamewithoutdomain");
MQEnvironment.SSLCertRevocationCheck = true;
We've established that the "CertificateLabel" is the "Friendly name" in Windows parlance.
We've proven unencrypted communication and network-level configuration.
We're using 8.0.0.7 client.
These are the issues we've come across:
All secure communications fail with a 2538 error. (MQRC_HOST_NOT_AVAILABLE, https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.tro.doc/q045380_.htm)
No success setting the Friendly Name to ibmwebspheremq and ibmwebspheremqmywindowsusername#domain and ibmwebspheremqmywindowsusernamewithoutdomain
General questions:
Are we correct in assuming that we can install generated certificates exclusively in the Windows Certificate Store?
Is the 2538 error even related to SSL communications? It feels like a network error, though there is that final point in the referenced error documentation.
Is there anywhere we can look for more informative error information? eg. relating to the SSL trust chain to see if there is an issue there?
The issue was the following line:
connectionProperties.Add(MQC.SSL_PEER_NAME_PROPERTY, "otherserver.com");
Turns out that:
It needs it in a canonical format, so DN=, etc.
You don't even need that line
Though we did learn a few things along the way:
The line:
connectionProperties.Add("CertificateLabel", "ibmwebspheremqmyusername");
Is the string ibmwebspheremq plus your Windows username (without your domain) and the label should be set on the Friendly name of your client machine's outgoing certificate NOT including the username.
The various folders inside your Windows certificate store are significant. The intermediate CAs should be correctly filed.
I'm trying to retrieve data from an open data api. I have downloaded the certificate from the site and imported it into STRUST (SSL Client Anonymous).
Then I created a HTTP connection to external server in SM59. In the beginning it worked fine, until last week when the api changed its URL and so its DNS.
Of course it could no longer be reached by the current host. So I did above steps again for the new URL (changed everything accordingly like hostname etc. in SM59), but this time I receive following error:
SSL handshake with 'hostname:port' failed: SSSLERR_CONN_CLOSED (-10)#Remote
Peer has closed the network connection##SapSSLSessionStartNB()==SSSLERR_CONN_CLOSED##
Anyone has an idea on how to solve this?
On another forum someone helped me solve the problem. He pointed me out that the problem lies with SNI see: https://security.stackexchange.com/questions/101965/ssl3-error-when-requesting-connection-using-tls-1-2/102018#102018
https://en.wikipedia.org/wiki/Server_Name_Indication
To solve this problem you need to add following parameter: icm/HTTPS/client_sni_enabled and set it to TRUE on the DEFAULT profile. Afterwards you need to restart the application server in order to activate the effects of the parameter.
Link to the full question on SCN: https://answers.sap.com/questions/473015/sap-ssl-handshake-failed.html
EDIT:
I came across this error again later on, but this time it seemed that the error was caused because we used a certificate with TLS 1.2 which was not supported by our system. You can check this link: https://launchpad.support.sap.com/#/notes/510007 we implemented number 7 to fix this.
I am trying to monitor https traffic with Fiddler, using current newest version:2.4.4.5
I've successfully set up https, certificates and I can see the full https encrypted traffic for example browsing my bank's web site.
...however...
When I trying to monitor an other server I got this error message in the response window:
"Failed to secure existing connection for 77.87.178.160. A call to SSPI failed, see inner exception. InnerException: System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm"
For full Fiddler window see:
The client is not a in this case browser, but a custom client program, which communicates with its own server.
My question: Is this exception misleading and in reality some other error prevents the secure channel to set up?
...or...
We have still chance to monitor this https communication?
Thx in advance
What is the client program?
This error typically indicates that that client application is only offering certain HTTPS ciphers, and those ciphers are not supported by Fiddler.
However, in this case, the specific problem here is almost certainly this: http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx
The client is trying to use AES with SSLv3, but that isn't one of the valid ciphers for SSL3. As a consequence, the connection fails.
You might be able to workaround this by clicking Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols =
System.Security.Authentication.SslProtocols.Ssl3;
Please let me know if this works.
NOTE Current versions of Fiddler offer a UI link for this: Look at the lis of enabled protocols on the HTTPS tab.
Unbelievably this issue is still present some 6 years later.
Just installed the latest version of Fiddle (v5.0.20194.41348), and sure enough on Win7 using Chrome or IE it keeps failing with the dreaded error:
"fiddler.network.https> HTTPS handshake to google.com (for #1) failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm"
After some hours of testing, I found a middle ground solution which seems to work with virtually all websites. The aim was to get the highest possible security with no errors in the log. Without needing to add any code, simply changing this line under Tools > Options > HTTPS > Protocols is what worked for me (just copy and paste it):
<client>;ssl3;tls1.1;tls1.2
Basically removed the ssl2 and tls1.0 protocols which leaves us with some pretty decent security and no errors so far. Having spent hours of frustration with this error, hope someone out there might find this useful, and a big thanks to EricLaw who discovered the root of the problem.
Yes I too have seen this error when working outside of fiddler and it was connected with AuthenticateAsServer but only went wrong when using IE10 and not Chrome as the browser.
Odd thing is that it did not break all the time for IE10 using SslProtocols.Tls for the protocol so I will add a bit of code to switch the protocol if one fails
The protocol that can be used also seems to change on if you are using a proxy server like Fiddler or using an invisible server by hijacking the DNS via the hosts file to divert traffic to the server