Antecedents to review

Recently, when I was helping users configure the SSO login page in a collaborative office software, I found an interesting thing. The login page that can be opened on iOS and PC was white on Android devices.

The following error message is displayed on the client:

{... "Ssl_Err_Info": {proceed: false, sslError=primary error: 3, ... }... }Copy the code

Primary error: 3 primary error: 3

Those of you who have consulted Android have been told that this is pre-installed by the system.

You can see the error message indicating that the certificate is not trusted, so what is the reason why the certificate is not trusted on the Android side?

Added concept

When you look at website certificates in Chrome, you can see that most certificates have a three-tier structure

1. DigiCert Global Root CA Root certificate, which is stored in our device

Encryption Everywhere DV TLS CA-G1 Intermediate Certificate

  • Certificate authorities (CAS) do not use root certificates directly to issue server certificates because this behavior is dangerous because every root signed certificate will be untrusted if it is issued incorrectly or if root needs to be revoked. Therefore, to protect the root certificate, the CA will issue the intermediate certificate and make the intermediate certificate trusted. Next, the CA uses the intermediate certificate to issue the end user’s server SSL certificate.

3. *. Juejin.cn SSL certificate

  • Generally, the ngnix CERTIFICATE file with the pem suffix starts with “—–BEGIN CERTIFICATE—–” and ends with “—–END CERTIFICATE—–“.

Validation rules

When we access HTTPS site resources, although the server has been configured with the relevant certificate, but how can the browser verify the validity of the certificate? The browser receives the certificate itself and the public key associated with the certificate. It uses the public key to verify the digital signature, sees what certificate the signer is signed with, and moves past the previous link, continues to authenticate the previous signature, and traces the chain of certificates that signed it — until eventually it reaches one of the root certificates in the browser truststore. If a certificate cannot be linked back to one of its trusted roots, it will not trust the certificate.

The whole process is a chain of certificates. Server certificate -> Intermediate certificate -> Root certificate

Root certificates are pre-installed on our devices/browsers, so where do intermediate certificates come from? Generally, the intermediate certificate information is included in the certificate in our configuration server. For detailed explanation, please refer to the certificate format description of Aliyun.

What happens if the configured certificate does not contain intermediate certificate information (that is, the certificate chain is incomplete)? The following will be divided into two cases. Here is an example site of an incomplete certificate chain, incomplete-chain.badssl.com/.

AIA fetching/browser cache

We will note that if you open incomplete-chain.badssl.com/ in Chrome, the browser will not report that the site certificate is untrusted, meaning that the browser has verified the entire certificate chain for the site.

So how does the browser verify intermediate certificates? We can download the certificate from the website and view the certificate information through the following tools.

openssl x509 -inform der -in \*.badssl.com.cer -noout -text
Copy the code

Authority Information Access here is a special extension in SSL certificates that contains Information about the issuer of the certificate. The browser can obtain the intermediate certificate by using the information in this section, and complete the entire certificate chain and pass the verification. If the browser has previously downloaded the same intermediate certificate, it will also cache it for later verification.

The certificate chain is incomplete and the server certificate is untrusted

Postman warning

Again with the same site, incomplete-chain.badssl.com/, what would it look like if we sent GET requests using Postman?

“Unable to verify the first certificate” was a response from Postman.

Android WebView white screen

As mentioned above, when the android client cannot be opened, both iOS and PC can be opened. This difference is due to the different handling strategies of AIA on different clients. Like most browsers will download the certificate according to the AIA Extension information in the certificate to complete the certificate chain verification, but different from other platforms, Android client will not do the certificate chain verification through AIA Extension by default.

How to repair

A recommended tool for checking website security is myssl.com/

If the certificate chain is incomplete after you enter the site domain name here, you will be prompted as follows.

Scrolling further down, we can see that the intermediate certificate information is missing

Because certificate information is public, click the certificate chain in the upper right corner to download the certificate. A complete certificate information including intermediate certificate information is automatically generated. You can use this certificate information to replace the certificate information configured on the server, and a complete certificate chain is added.

summary

  • When configuring the SSL certificate for the server, add intermediate certificate information to form a complete certificate chain
  • AIA fetching can complete an incomplete certificate chain to pass verification
  • Android WebView does not use AIA Extension to verify certificate chains by default