Fix ERR_SSL_CLIENT_AUTH_NO_COMMON_ALGORITHMS (Pakistan Guide)

When developing, testing, or integrating Mutual TLS (mTLS) interfaces in Pakistan—such as State Bank of Pakistan (SBP) Open Banking APIs, Raast payment gateways, corporate ERP integrations, or microservice service meshes—engineers frequently encounter a fatal client handshake rejection in Google Chrome or Microsoft Edge:

This site can’t provide a secure connection
api.fintech.bank.pk didn’t accept your client certificate, or one was not provided.
Try contacting the system administrator.
ERR_SSL_CLIENT_AUTH_NO_COMMON_ALGORITHMS

Unlike basic certificate expiration or untrusted root errors, this error explicitly indicates a cryptographic protocol mismatch. During the TLS 1.3 handshake, the server requested a client certificate, but none of the signature algorithms supported by the server overlapped with the digital signature on the client certificate presented by the browser or API caller.

---

1. Cryptographic Mechanics of the mTLS Handshake

In Mutual TLS, authentication is bidirectional. Not only does the browser verify the server’s identity, but the server also verifies the client.

During the TLS handshake, the server transmits a CertificateRequest frame containing:

1. Supported Signature Algorithms (e.g., ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256).
2. Supported Certificate Authorities (Acceptable CA Names).

[Client Browser / API Gateway]                           [Enterprise Banking Server]
            │                                                         │
            ├─── ClientHello (TLS 1.3) ──────────────────────────────►│
            │◄── ServerHello + Certificate + CertificateRequest ──────┤
            │    (Accepts ONLY: ecdsa_secp256r1_sha256, rsa_pss)      │
            │                                                         │
            ├─── Client Certificate Presented: ──────────────────────►│
            │    (Signed with: sha1WithRSAEncryption or PKCS#1 v1.5)  │
            │                                                         │
            │◄── Alert: Fatal Handshake Failure ──────────────────────┤
            ▼    (ERR_SSL_CLIENT_AUTH_NO_COMMON_ALGORITHMS)

If the client presents a certificate generated with legacy algorithms (such as SHA-1, MD5, or RSA PKCS#1 v1.5 that are disabled under OpenSSL 3.x), the handshake terminates instantly.

Running high-concurrency mTLS financial gateways requires dedicated hardware crypto acceleration and zero noisy-neighbor jitter. Discover our high-performance Dedicated Servers and localized Dedicated Servers in Pakistan engineered for enterprise banking architectures.

---

2. Inspecting the Client Certificate via OpenSSL CLI

To identify why the client certificate was rejected, inspect its signature algorithm, key size, and public key format:

# Inspect the client certificate
openssl x509 -in client.crt -noout -text | grep -E "(Signature Algorithm|Public Key Algorithm|Subject:)"

Typical Failing Output:

    Subject: CN=Merchant_API_Client, O=Payment Services PK, C=PK
    Signature Algorithm: sha1WithRSAEncryption
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            RSA Public-Key: (1024 bit)

The Flaw:

The certificate uses a 1024-bit RSA key and sha1WithRSAEncryption. Modern servers running OpenSSL 3.x (with default SECLEVEL=2) reject RSA keys under 2048 bits and refuse all SHA-1 signatures in TLS handshakes.

---

3. Server-Side Diagnosis: Querying Supported Client Algorithms

You can test what signature algorithms the server requests by running openssl s_client:

openssl s_client -connect api.fintech.bank.pk:443 -servername api.fintech.bank.pk -msg </dev/null 2>&1 | grep -A 10 "CertificateRequest"

Look for the signature_algorithms extension. In TLS 1.3, modern servers mandate:

• ecdsa_secp256r1_sha256 (0x0403)
• rsa_pss_rsae_sha256 (0x0804)
• rsa_pss_rsae_sha384 (0x0805)

If your client certificate is signed with legacy rsa_pkcs1_sha256 and the server enforces TLS 1.3 without legacy fallback, the handshake fails with NO_COMMON_ALGORITHMS.

---

4. Remediation: Re-issuing Modern ECDSA P-256 Client Certificates

The industry-standard solution is re-issuing modern client certificates using Elliptic Curve Cryptography (prime256v1 / P-256) or RSA 2048 with SHA-256.

Generating an Ultra-Fast ECC Client Certificate

# 1. Generate EC private key
openssl ecparam -name prime256v1 -genkey -noout -out client_ecc.key
chmod 0600 client_ecc.key

# 2. Create OpenSSL client certificate configuration (client.cnf)
cat << 'EOF' > client.cnf
[ req ]
default_md          = sha256
distinguished_name  = req_distinguished_name
prompt              = no

[ req_distinguished_name ]
C                   = PK
ST                  = Sindh
L                   = Karachi
O                   = Fintech Solutions PK
CN                  = Merchant_API_Client_2026

[ client_ext ]
basicConstraints    = CA:FALSE
keyUsage            = critical, digitalSignature, keyAgreement
extendedKeyUsage    = clientAuth
subjectAltName      = @alt_names

[ alt_names ]
email.1             = [email protected]
EOF

# 3. Generate CSR
openssl req -new -key client_ecc.key -config client.cnf -out client_ecc.csr

# 4. Sign with Internal Enterprise CA
openssl x509 -req -days 365 -in client_ecc.csr \
    -CA /etc/ssl/ca/enterprise_ca.crt \
    -CAkey /etc/ssl/ca/enterprise_ca.key \
    -CAcreateserial \
    -extfile client.cnf \
    -extensions client_ext \
    -sha256 \
    -out client_ecc.crt

Packaging into PKCS#12 (.p12) for Windows Browser Import

Browsers require client certificates to be imported in PKCS#12 format:

# Export certificate and private key to password-protected .p12
openssl pkcs12 -export -out client_ecc.p12 \
    -inkey client_ecc.key \
    -in client_ecc.crt \
    -certfile /etc/ssl/ca/enterprise_ca.crt

Double-click client_ecc.p12 in Windows, import it into the Personal certificate store, restart Google Chrome, and select the newly installed certificate when prompted.

---

5. Server-Side Configuration Tuning (Nginx / Apache)

If you control the server and must maintain backward compatibility for existing legacy clients across Pakistan during a migration window:

Nginx mTLS Configuration

server {
    listen 443 ssl http2;
    server_name api.fintech.bank.pk;

    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;

    # Enable Client Certificate Authentication
    ssl_client_certificate /etc/ssl/ca/trusted_clients_ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;

    # Broaden allowed TLS 1.2 / TLS 1.3 signature algorithms if needed
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
    ssl_ecdh_curve X25519:prime256v1:secp384r1;
}

Reload Nginx:

nginx -t && systemctl reload nginx

Chrome will now negotiate the mutual authentication handshake cleanly without dropping connections.

For complementary browser certificate security diagnostics, review our guides on How to fix SEC_ERROR_MITM_DETECTED in Firefox and How to fix ERR_CERT_CONTAINS_ERRORS in Chrome. If you run isolated microservices or containerized backends, explore our Cloud VPS hosting solutions.

---