CEF Forum

We're seeing an issue where redirects during SSO sign-on flows are throwing OnLoadErrors with ERR_SSL_CLIENT_AUTH_CERT_NEEDED.

This issue isn't reproducible with CefSharp v81 (our previous release), but is now showing on CefSharp v91.1. Has something changed in terms of SSL auth handling? I found another issue that looks eerily similar here: https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=18455&start=0, but it's not quite the same thing.

This issue looks to exclusively happen during redirects, as when we directly load the failed URL after catching the error the page loads successfully.

Any insight into potential fixes here?

Thanks!

I have already posted the same a few months ago viewtopic.php?f=6&t=18437

I can confirm that this problem starts with CEF v90. We did some tests on a customer machine where this problem still occurs and tried with cefclient v89, cefclient v90 and cefclient v91. With cefclient v89 there was no problem and the redirect from https://example.com:port1 to https://example.com:port2 works without problems. Beginning with cefclient v90 an OnLoadError with ERR_SSL_CLIENT_AUTH_CERT_NEEDED is thrown and the request is aborted.
This problem is not solved yet and still appears with v94.

A workaround was to automatically reload the request, but this works only fine for main frames and not for sub frames. Another problem of this reload approach is that in our case the following NTLM authentication (which happens after the redirect) is not done correctly, because the negotiate step is intercepted.

We have recorded some fiddler traces and it seems that the response after the redirect is correctly send from the server, but on client side (CEF/Chromium based browser control) the LoadError is thrown. We checked everything (SSL configuration, Server response) and cannot find any error with this. SSL must be correct, because there is no problem if we directly start with https://example.com:port2 and it works also in all other standard browsers + IE webbrowser control and earlier CEF versions.

So from our point of view there must be a bug or a wrong behaviour in CEF itself. Unfortunately it is not possible to provide a public available and reproducible scenario where exactly the same problem occurs.
It is also not possible to debug CEF, because we cannot do this on customer systems.

I searched the forum a lot and it seems that there are some others reporting problems with redirects, NTLM authentication problems and situation where OnCertificateErrors and OnLoadErrors are mixed up.

I really appreciate some help on this (for example a starting point to search CEF code and diff between 89 and 90) or maybe the thread opener can provide a reproducible scenario.
This really starts to hurt our customer as we cannot provide a fix or workaround.

The workaround may be running with the “--disable-request-handling-for-testing” command-line flag and using a supported CEF version.

I have checked with cefclient.exe --disable-request-handling-for-testing (v94.4.10) and indeed it seems to fix the problem.
A few months ago I already tested the same flag with our own application but without success. At that time I think we have built with 91.1.12+gcf0c26a+chromium-91.0.4472.101 and I thought that this flag was already committed for this version. But maybe I was wrong or it was a problem with our command line implementation (did not explicitly check with cefclient).

Now it seems to be fine, but to be honest the name of the flag does not suggest that it should be used in production environments
As I understand, using this flag means that CEF just let the requests (http/https) pass through without any further processing and let Chromium itself do the job.
Are there any possible negative sideeffects or any known limitations in regards to the CEF API (missing request callbacks or something else...) ?

samohtt wrote:Now it seems to be fine, but to be honest the name of the flag does not suggest that it should be used in production environments

Indeed, the flag is primarily for testing purposes. The underlying bug should still be fixed in CEF, if possible.

samohtt wrote:As I understand, using this flag means that CEF just let the requests (http/https) pass through without any further processing and let Chromium itself do the job.

Correct.

samohtt wrote:Are there any possible negative sideeffects or any known limitations in regards to the CEF API (missing request callbacks or something else...) ?

You won't get most network-related callbacks for HTTP/S requests while using the flag.

Thanks for the replies! We'll check out the possible workarounds as a temporary solution. Where is the best place for us to cut a tracking item for getting this bug fixed in CEF?

sometestusername wrote:Thanks for the replies! We'll check out the possible workarounds as a temporary solution. Where is the best place for us to cut a tracking item for getting this bug fixed in CEF?

Please file a bug at https://bitbucket.org/chromiumembedded/cef/issues/new. It will help a lot of you can provide reproduction steps.

magreenblatt wrote:

sometestusername wrote:Thanks for the replies! We'll check out the possible workarounds as a temporary solution. Where is the best place for us to cut a tracking item for getting this bug fixed in CEF?

Please file a bug at https://bitbucket.org/chromiumembedded/cef/issues/new. It will help a lot of you can provide reproduction steps.

Thanks for the help
Here's the issue https://bitbucket.org/chromiumembedded/ ... rrors-with

There is now a trial fix linked from the issue. Please try a build with that fix and report back whether the problem is resolved or still reproduces for you.