Solving Android SSL Certificate Expiration: HuoLaLa’s Full Debugging Guide

Background

In 2020 the HuoLaLa Android client aligned its network communication with an SSL certificate verification scheme, but a mis‑configured certificate caused validation failures days before the built‑in certificate expired, leading to a full‑network outage.

SSL Certificate Basics

SSL (Secure Sockets Layer) was introduced by Netscape in 1994 to provide encryption, server authentication, message integrity, and optional client authentication for protocols such as HTTP, FTP, and Telnet. HTTPS = HTTP + TLS/SSL.

Certificate Types

Two main categories exist: CA certificates (root and intermediate) and user certificates (server and client). Root certificates are the trust anchor; intermediate certificates protect the root by signing other certificates.

Certificate Chain

A chain links a user certificate to its issuing intermediate certificates and ultimately to a single root CA certificate.

File Extensions

Common extensions include .key (private key), .csr (certificate signing request), .crt / .cert (public certificate), and .pem (combined key and certificate).

User Certificate Types

Domain‑validated (DV), organization‑validated (OV), and extended‑validation (EV) certificates differ in the level of identity verification required.

Certificate Structure and Viewing

Tools such as Chrome’s certificate viewer can be used to inspect a server’s certificate, its subject, issuer, validity period, and public key.

Android Client SSL Verification Process

Handshake Overview

The SSL/TLS handshake exchanges keys and authenticates the server. Validation occurs mainly in step 3 (Certificate) and step 6 (certificate legitimacy check).

Verification Steps

Confirm the certificate is issued by a trusted CA root.

Validate the server’s public key and its digest against the stored CA public key.

Check the certificate against revocation lists (CRL) or OCSP.

Verify the certificate’s Validity period has not expired.

Ensure the certificate’s domain matches the requested host.

Revocation Strategies

Android defaults to CRL verification via CertBlocklistImpl, which maintains a local blacklist stored under ANDROID_DATA/misc/keychain/pubkey/blacklist.txt. OCSP can be used for real‑time status checks.

Custom Revocation Logic

Developers can customize verification by using TrustManagerFactory, CertPathTrustManagerParameters, and PKIXRevocationChecker. Example code shows how to load a client keystore ( client.bks) and a truststore ( publickey.bks), initialize SSLContext, and obtain an SSLSocketFactory for secure connections.

public class SSLHelper {
    private static final String CLIENT_PRI_KEY = "client.bks";
    private static final String TRUSTSTORE_PUB_KEY = "publickey.bks";
    private static final String CLIENT_BKS_PASSWORD = "123321";
    private static final String KEYSTORE_TYPE = "BKS";
    private static final String PROTOCOL_TYPE = "TLS";
    private static final String CERTIFICATE_STANDARD = "X509";

    public static SSLSocketFactory getSSLCertifcation(Context context) {
        // Load keystore and truststore, initialize SSLContext, etc.
    }
}

Certificate Validation Modes in Android

Certificate pinning (subject & public key match).

Public‑key pinning (only public key match).

Mutual TLS (both client and server present certificates).

Trust‑all mode (no verification, discouraged).

Certificate Pinning Implementation

Can be configured globally via network-security-config (Android 7.0+) or programmatically by setting a custom SSLSocketFactory. Pinning to the full certificate provides stronger protection but fails when the certificate expires or its subject changes (e.g., missing OU field).

Public‑Key Pinning Implementation

Only the server’s public key is compared, allowing certificate renewal without changing the pin, but offering slightly lower security.

Mutual TLS Implementation

Both sides exchange certificates; the client loads its private key and the server’s trusted certificates, then creates an SSLContext with both KeyManagerFactory and TrustManagerFactory.

Trust‑All Implementation

Disables verification entirely; useful for testing but insecure for production.

Debugging Android Certificate Verification

Because the verification code resides outside android.jar, developers can download the AOSP source (e.g., platform/external/conscrypt) matching the device’s Android version, import it as a separate module, and set breakpoints in classes such as TrustManagerImpl and TrustedCertificateIndex to observe the validation flow.

Key Source Classes

CertificateSource

– interface for obtaining certificates. KeyStoreCertificateSource – loads certificates from a KeyStore. ResourceCertificateSource – loads from app resources. DirectoryCertificateSource – scans a directory; subclasses SystemCertificateSource and UserCertificateSource define system and user paths.

Verification Logic

TrustManagerImpl.checkServerTrusted()

delegates to checkTrusted(), which uses TrustedCertificateIndex to match the issuer’s X500Principal and signature. The X500Principal equality checks both the public key and subject fields (including OU).

HuoLaLa SSL Incident

In July 2020 the client used certificate pinning. In August 2022 the server rotated its certificate without the OU field, causing Android’s pinning to reject the new certificate. Multiple attempts (keeping the old certificate, matching public keys, adding intermediate certificates) failed because Android also validates the subject.

The final fix was to obtain a new server certificate that included the original OU field, then update the app’s pinning configuration.

Recommended Solutions

Choose an authentication level: mutual TLS > certificate pinning > public‑key pinning.

Implement verification using the appropriate pinning method and consider encrypting pins in native code for extra protection.

Provide dynamic configuration to push new pins or certificates early.

Enable a fallback that can disable pinning temporarily if verification fails, preventing total service outage.

Conclusion

Understanding SSL certificate types, Android’s verification flow, revocation mechanisms, and the impact of subject fields is essential for building robust mobile security. Access to the Android source code and proper debugging practices can prevent costly incidents like the HuoLaLa outage.

References: https://www.cnblogs.com/xiaxveliang/p/13183175.html https://blog.csdn.net/weixin_35016347/article/details/105802480