ClassNotFoundException: B in X509CertificateInvoker.GetEncoded() during TLS handshake — regression after .NET 9 → .NET 10 upgrade

[JeroenBer]

Android framework version

net10.0-android

Affected platform version

.NET 10.0

Description

After upgrading a MAUI/.NET for Android app from net9.0-android to net10.0-android (no other code changes to networking/certificate validation), we started seeing repeated crashes in production/test logs with Java.Lang.ClassNotFoundException: B

With the following stacktraces:

Java.Lang.ClassNotFoundException: B
at Java.Interop.JniEnvironment.Types.TryFindClass(String , Boolean )
at Java.Interop.JniEnvironment.Types.FindClass(String )
at Android.Runtime.JNIEnv.FindClass(Type )
at Android.Runtime.JNIEnv.AssertCompatibleArrayTypes(IntPtr , Type )
at Android.Runtime.JNIEnv._GetArray(IntPtr , Type )
at Android.Runtime.JNIEnv.GetArray(IntPtr , JniHandleOwnership , Type )
at Java.Security.Cert.X509CertificateInvoker.GetEncoded()
at Xamarin.Android.Net.ServerCertificateCustomValidator.TrustManager.Convert(X509Certificate[] )
at Xamarin.Android.Net.ServerCertificateCustomValidator.TrustManager.CheckServerTrusted(X509Certificate[] , String )
at Javax.Net.Ssl.IX509TrustManagerInvoker.n_CheckServerTrusted_arrayLjava_security_cert_X509Certificate_Ljava_lang_String_(IntPtr jnienv, IntPtr native__this, IntPtr native_chain, IntPtr native_authType)
--- End of managed Java.Lang.ClassNotFoundException stack trace ---
java.lang.ClassNotFoundException: B
at xamarin.android.net.ServerCertificateCustomValidator_TrustManager.n_checkServerTrusted(Native Method)
at xamarin.android.net.ServerCertificateCustomValidator_TrustManager.checkServerTrusted(ServerCertificateCustomValidator_TrustManager.java:29)
at com.android.org.conscrypt.Platform.checkServerTrusted(Platform.java:342)
at com.android.org.conscrypt.ConscryptEngine.verifyCertificateChain(ConscryptEngine.java:1558)
at com.android.org.conscrypt.NativeCrypto.ENGINE_SSL_read_direct(Native Method)
at com.android.org.conscrypt.NativeSsl.readDirectByteBuffer(NativeSsl.java:685)
at com.android.org.conscrypt.ConscryptEngine.readPlaintextDataDirect(ConscryptEngine.java:997)
at com.android.org.conscrypt.ConscryptEngine.readPlaintextData(ConscryptEngine.java:981)
at com.android.org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:776)
at com.android.org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:647)
at com.android.org.conscrypt.ConscryptEngine.unwrap(ConscryptEngine.java:612)
at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.processDataFromSocket(ConscryptEngineSocket.java:928)
at com.android.org.conscrypt.ConscryptEngineSocket$SSLInputStream.-$$Nest$mprocessDataFromSocket(ConscryptEngineSocket.java:0)
at com.android.org.conscrypt.ConscryptEngineSocket.doHandshake(ConscryptEngineSocket.java:243)
at com.android.org.conscrypt.ConscryptEngineSocket.startHandshake(ConscryptEngineSocket.java:225)
at com.android.okhttp.internal.io.RealConnection.connectTls(RealConnection.java:196)
at com.android.okhttp.internal.io.RealConnection.connectSocket(RealConnection.java:153)
at com.android.okhttp.internal.io.RealConnection.connect(RealConnection.java:116)
at com.android.okhttp.internal.http.StreamAllocation.findConnection(StreamAllocation.java:186)
at com.android.okhttp.internal.http.StreamAllocation.findHealthyConnection(StreamAllocation.java:128)
at com.android.okhttp.internal.http.StreamAllocation.newStream(StreamAllocation.java:97)
at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:289)
at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:232)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:465)
at com.android.okhttp.internal.huc.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:131)
at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.connect(DelegatingHttpsURLConnection.java:90)
at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:30)

We do use Xamarin.Android.Net.AndroidMessageHandler() with ServerCertificateCustomValidationCallback. That might be related.
We have not been able to reproduce this problem on our testdevices. We see the problem for around 200+ unique users on Android.

We do use:

• .NET SDK Version'10.0.110'
• AndroidWorkloadVersion '10.0.301.1'
• AOT

We don't use:

• R8 Code Shrinker
• LLVM optimizing compiler

Steps to Reproduce

We have not been able to reproduce this on our own test devices.

We do see it many times for hundreds of unique users on different devices/android versions (29, 30, 31, 32, 33, 34, 35, 36).

Did you find any workaround?

No workaround available.

Relevant log output

[simonrozsival]

Thanks for the report. We added focused coverage for X509CertificateInvoker.GetEncoded() and the AndroidMessageHandler custom certificate-validation path, but we have not been able to reproduce the failure. We also tested an app using the exact reported .NET SDK/workload versions (10.0.110 / 10.0.301.1) with Release AOT on an emulator and a physical Samsung device; 1,000 repeated GetEncoded() calls completed successfully.

To investigate further, could you provide a minimal reproducible project that exhibits the failure, including the relevant AndroidMessageHandler configuration and publish/build properties? If it only occurs in production, a stripped-down project that retains the same certificate callback, AOT settings, trimming settings, and affected dependencies would help us identify the missing condition.

[JeroenBer]

Thanks for looking into it. I haven't been able to reproduce it myself yet. I can only see that it happens a lot in production after .NET 9 to .NET 10 upgrade.
But I will test further if I can find a repro path and build a repro solution.