answering my own questions:
This has somehow changed and now AUTH_USER always contains the username. This has fatal consequences as no every owner of a valid certificate can logon as any user.
I now use auth_ssl_username_from_cert = yes and this temporarily fixes my problem. Now if user A authenticates with his certificate and claims to be user B he will be logged on as user A. With ssl_username_from_cert = no (default) he was logged in as User B.
I'm absolutely sure that the value of the x500UniqueIdentifier was stored into the AUTH_USER when I tested my setup last year.
If one looks at the source code, in particular routine env_put_auth_vars() in src/auth/db-checkpassword.c and routine auth_request_get_var_expand_table() in src/auth/auth-request.c it is clear, that this has never worked.
The environemnt variable AUTH_USER always contais the username (in all Dovecot versions). It dows NOT contain the Dovecot auth_user-variable. Comparing AUTH_USER with the username makes no sense in a checkpassword-script
So here's my next question: How do I find out the original username from within a chackpassword script after it has been replaced by the x500UniqueIdentifier value from a client certificate?
Why is request->requested_login_user == NULL in env_put_auth_vars(). request->user contains the x500UniqueIdentifier value from the clients certificate so the original username was replaced and therefore should have been moved into request->requested_login_user.
Kind regards
Peter Koch