Chrome cookies not working after tomcat web server reboot

I was able to reproduce your problem with Chrome: Just it is needed to create HttpSession from HTTPS zone. Any subsequent HTTP request will not send the session cookie and any attempt to Set-Cookie:JSESSIONID= through HTTP is ignored by chrome.

The problem is localized when the user switch from HTTPS to HTTP. The HTTPS session cookie is maintained even if server is restarted and is working properly. (I tested with Tomcat6, Tomcat 9, and using an apache proxy for SSL)

This is response header sent by Tomcat when session is created from HTTPS

 Set-Cookie: JSESSIONID=CD93A1038E89DFD39F420CE0DD460C72;path=/cookietest;Secure;HttpOnly

and this one for HTTP (note Secure is missing)

 Set-Cookie:SESSIONID=F909DBEEA37960ECDEA9829D336FD239;path=/cookietest;HttpOnly

Chrome ignores the second set-Cookie. On the other hand Firefox and Edge replace the Secure cookie with the not-secured. To determine what the correct behaviour should be I have reviewed RFC2109

4.3.3 Cookie Management

If a user agent receives a Set-Cookie response header whose NAME is the same as a pre-existing cookie, and whose Domain and Path attribute values exactly (string) match those of a pre-existing cookie, the new cookie supersedes the old.

So, It is clear is a chrome bug, as you supposed in the question: The HTTP cookie should replace the one setted by HTTPS

Removing cookie manually from Chrome or invalidating the session at server side makes it work again (if after these actions the session is created using HTTP)

By default the JSESSIONID cookie is created with Secure when is requested from HTTPS. I guess this is the reason that Chrome do not allow to overwrite the cookie. But if you try to set <secure>false</secure> in web.xml Tomcat ignores it and the Set-Cookie header is sent with Secure

<session-config>    <cookie-config>        <http-only>true</http-only>        <secure>true</secure>    </cookie-config></session-config>

Changing cookie name, setting sessionCookiePathUsesTrailingSlash or removing HttpOnly has had no effect

I could not find a workaround for this issue except invalidating server session when logged user switch from HTTPS to HTTP.

Finally I opened a bug in chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=698839

UPDATEDThe issue is finally marked as Won't Fix because it is an intentional change. See https://www.chromestatus.com/feature/4506322921848832

Strict Secure Cookies

This adds restrictions on cookies marked with the 'Secure' attribute. Currently, Secure cookies cannot be accessed by insecure (e.g. HTTP) origins. However, insecure origins can still add Secure cookies, delete them, or indirectly evict them. This feature modifies the cookie jar so that insecure origins cannot in any way touch Secure cookies. This does leave a carve out for cookie eviction, which still may cause the deletion of Secure cookies, but only after all non-Secure cookies are evicted.

I remember seeing this a couple of times and as far as I can remember this was the only recommendation on the matter, as you mentioned:

A possible solution to this might be adding sessionCookiePathUsesTrailingSlash=false in the context.xml and see how that goes.

Some info on the matter from here

A discussion here (same solution)

Hope I didn't confuse the issues and this helps you, let me know with a comment if I need to edit/if worked/if I should delete, thanks!

There is a draft document to deprecate the modification of 'secure' cookies from non-secure origins (submitted by Google). It specifies the recommendations to amend the HTTP State Management Mechanism document.

Abstract of the document:

This document updates RFC6265 by removing the ability for a non-
secure origin to set cookies with a 'secure' flag, and to overwrite
cookies whose 'secure' flag is set. This deprecation improves the
isolation between HTTP and HTTPS origins, and reduces the risk of
malicious interference.

Chrome already implemented this feature in v 52 and same feature is also implemented in Mozilla few days back.

To solve this issue, I think you should connect to website via https only.