If the request is over https out of the box should be setting the secure flag on all cookies. In case you are terminating SSL on another layers like lb, dispatcher configure Felix SSL Filter. You can also set using api.
I know this is an old question, but our team ran into it recently and found a solution that may be helpful to others.
I decompiled AEM's TokenUtil class and tried to find the place where the login-token cookie is set, and the secure flag is set or not based on the request's isSecure() method. If the request is secure, then the flag is set. Otherwise, it's not. So the question really becomes: how do we get the request to be marked as secure.
It ends up there's a few solutions here. The first is to connect over HTTPS. Obviously this works, but in cases where there's a proxy or load balancer, the connection is often over HTTP. It's pretty well understood that a X-Forwarded-Proto header can be used in this case to tell the origin server that a proxied connection was secure. However, in our case this header was being set, but the request object was still not "secure".
It ends up that these headers are simply not honored all the time by Jetty. There is a flag in the Apache Felix Jetty Based HTTP Service that handles this, but it is not the obvious one, which is "Session Cookie httpOnly". This refers to the JESSIONID cookie, not the login-token cookie, and so this checkbox has no affect.
The true solution is to ensure that "Enable Proxy/Load Balancer Connection" is checked in the Apache Felix Jetty Based HTTP Service configuration. It seems like Jetty will not honor the XFF headers if this value is not true. Checking this box caused the secure flag to be added to our Set-Cookie header through a proxied connection.
tl;dr - set Enable Proxy/Load Balancer Connection to true in the Apache Felix Jetty Based HTTP Service configuration.