I logged in to my app and the TSL certificate has expired after 15 minutes. I renewed an expired certificate and I couldn't log in, however after clearing my browser's cookies
I was able to login again.
My questions
Why did I need to clear browser cookies to be able to log in?
Are cookies somehow related to TSL certificate / (-es)?
Do old cookies become invalid upon TSL certificate expiration?
Are these issues specific to a given situation or is it a common behavior that an expired certificate makes a cookie invalid or is it something else (perhaps, app specific)?
TLS certificates and cookies have nothing in common, they are totally independent. Cookies may contain encrypted data but that might be tied to some other certificate or private/public-key but this is still independent from the TLS cert.
Related
I was trying to observe TLS flow if a website has a revoked certificate. Then I found a test website "https://revoked.grc.com/" and send a request over Google Chrome while I was capturing packets via Wireshark.
During TLS, the server (https://revoked.grc.com/) sent me a revoked certificate and certificate status which has "REVOKED", then I displayed "NET::ERR_CERT_REVOKED" error on Google Chrome as I expected.
I have also expected to display an error like "Handshake Failure" or "Bad Certificate" on Wireshark, but when I filtered TLS flow on Wireshark, I saw that the key exchange is done!
screen shot of wireshark
Is there any idea why Wireshark capture is like that? Is it a security vulnerability of Google Chrome?
Thanks
No. It's because a certificate is valid as long as the signature is valid and the date is within the current valid range. The only way a browser (or other system) knows that a certificate is revoked is to consult a CRL using OCSP or, as is often the case for a server, a local CRL.
If you mark a certificate as revoked in your PKI, you are creating an entry in the CRL. The certificate itself is not changed. If you had to change the certificate, you would have no way to revoke a certificate that you did not have physical possession of.
We have just setup a web site , IE and firefox works fine to access it , but when use Chrome , the https is not works , it pops the below error , would advise how can I fix it ? thanks
mysite.com
identity not verified.
the identity of this website has been verified by geo trust ssl CA but does not have public audit records.
the site is using outdate security setting that may prevent future version of Chrome from being able to safely access it.
Your connection to mysite.com is encrypted with obsolete cryptography.
the connection uses TLS 1.2.
the connection is encrypted using RC4_128 with SHA1 for message authentication and RSA as the key exchange mechanism.
If you see an SSL error message in Chrome saying "Your connection is not private," it means your Internet connection, or your computer, is stopping Chrome from loading the page securely.
If you are a web user and you see this warning, you can contact the site owner to make sure that they are aware of the warning. The site is no less secure today than it was last month, but Google is starting to bring awareness to the less secure SHA-1 signed certificates.
The certificate is unable to be audited. In other words, it does not
have the necessary information to be able to go to the CA and check if
the certificate has been manually revoked prior to its expiration.
HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome's user interface.
References :
Check connection to a website here.
Sunsetting SHA-1 - blog
Also more at security.exchange
I am writing to check if anyone has had a similar issue with Jasig CAS.
We are basic facing infinite redirects in the browser (In firefox: "Firefox has detected that the server is redirecting the request for this address in a way that will never complete.") after being able to log in CAS. It seems the client side does not get properly the authentication details ?
Since we have not done any code change, I think this is because a certificate change we did last night. We had a new ssl certificate from Verisign which we are using in all our servers., matching the server against our root domain.
Verisign certificate seem correct, and also intermediate ones...
Don't know if the old certificate could be cached somewhere in CAS or what could be the problem as to why the client and cas keep redirecting themselves, all only after we uploaded the new certificate into the Load Balancer (as the old one was expired).
Any ideas?
Disclaimer: I'm the Chairman of CAS and founder of CAS in the cloud (https://www.casinthecloud.com).
My guess would be that the new certificate, even if it works properly from a browser, doesn't work properly for a direct call directly from the application in the JVM (bad intermediate certificate for example). So, the service ticket validation fails and if the error page is protected, the user is sent to the CAS server which redirects him back to the application for service ticket validation and so on. Thus, the infinite loop...
I am developing browser extension, that sends some data from currently browsed page to my backend server. User is aware of it, it is intended.
I don't want to cause any user-data exposure, when the user is e.g. on unsecured wifi. So I just want to ensure, the data and the url goes over the net encrypted and only my backend will see them.
Do I understand correctly, that any SSL certificate, even free one from StartSSL will do the trick?
What other side effects with free SSL certificate should I consider?
- will the user's http-client trust such a certificate?
Thanks.
The SSL certificate will do the trick as long as it can be validated. That means that the root certificate of the certificate chain needs to be within the trusted certificate store of the browser.
Furthermore, the certificate will have to be for the right address (URL), must not be revoked, CRL's and OCSP must be configured correctly etc. etc. In other words, the usual steps required to have your web-service certificate validated must be met.
When the SSL certificate is revoked, some browsers (including modern ones) don't fetch the new certificate from the server, so about 0.1% of the clients are getting "Revoked certificate" error page and they can't access the service securely. The problem on the client side is solved by clearing browser's cache. However not everybody does it. Most people just close the page as fast as they can, as the error message tends to say "the authenticity of the received data could not be verified" and "report this broken site"..
Is there a way to configure HAProxy, which is working as SSL offloader in front of the web server cluster, to allow connections to be established using the "old" certificate, while all the negotiations and renegotiations are served using the "new" certificate?
P.S. This problem is partially caused by HAProxy SSL session cache, which is crucial with our load, so it can't be disabled.
The certificate of he server is sent inside each full handshake and a validation of the certificate is only done when a certificate is received and is done against the received certificate, not anything cached. But, it might happen that clients refuse to establish a connection if the fingerprint of the certificates does not match the one they've received earlier within the browser session. Or it might be, that they use implicit certificate pinning (with a browser extension), which will detect if the new certificate conflicts with an earlier received certificate and complain about it.
There is nothing you can do about it. All you get from the client at the start of the SSL handshake is the ClientHello record. This might contain the name of the target host (if SNI is used) but there is no information about any old certificates the client might have seen. This means, that the server has no information on which it could decide, if it should send the new or the older certificate for the same hostname.