It's 2018 now, and all of Stack Exchange should be on HTTPS, even Area 51. But logging in to Area 51 using SE OpenID with HTTPS Everywhere is still broken, giving the following error:
Unable to log in with your OpenID provider:
The openid.return_to parameter (http://area51.stackexchange.com/users/authenticate/?s=11111111-1111-1111-1111-111111111111&dnoa.userSuppliedIdentifier=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000) does not match the actual URL (https://area51.stackexchange.com/users/authenticate/?s=11111111-1111-1111-1111-111111111111&dnoa.userSuppliedIdentifier=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000&openid.claimed_id=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000&openid.identity=https%3A%2F%2Fopenid.stackexchange.com%2Fuser%2F00000000-0000-0000-0000-000000000000&openid.sig=...) the request was made with.
(Remainder of the very long URL omitted; GUIDs anonymized, just in case.)
Without HTTPS Everywhere, logging in works, but takes a detour through an insecure HTTP URL:

It looks like the problem is that the Area 51 OpenID authentication code still sends a hardcoded http://
return URL to the provider, which then redirects back to it. With HTTPS Everywhere active, this return request gets rewritten to use HTTPS — but this means that the actual request URL no longer matches the signed copy of the openid.return_url
parameter included with it. And the authentication code, observing that something fishy is going on, refuses to complete the login.
In principle, it should be possible to work around the error with an extra HTTPS Everywhere rule that would rewrite the return URL in the initial, unsigned request to the OpenID provider. But such a workaround would not solve the actual underlying problem, i.e. that without HTTPS Everywhere the login process here on Area 51 still goes through a non-HTTPS URL.