How to extract intermediate and root CA certificates from the certificate chain using OpenSSL
Issue:
------
When inspecting the SSL/TLS certificate for here endpoints such as router.hereapi.com customers see a leaf certificate that expires in 2027 and may consider this validity period too short. At the same time, the intermediate CA (GlobalSign RSA OV SSL CA 2018) expires in 2028, and the root CA (GlobalSign Root CA-R3) expires in 2029.
However, downloading the certificate chain directly from the server only returns the leaf and intermediate certificates. The root CA is not transmitted during the TLS handshake and must be obtained separately. Additionally, GlobalSign operates multiple root CAs (R1, R2, R3) with different expiry dates, and downloading the wrong root (for example, R1, which expires in 2028) will not match the actual chain used by HERE API endpoints.
Note: Short leaf certificate validity is expected and intentional. Starting in March 2026, CA/Browser Forum changes begin to reduce TLS certificate lifetimes, with GlobalSign and other CAs moving towards a maximum of roughly 199 days and eventually shorter validity over time. Customers should not pin the leaf certificate but should instead anchor trust to the intermediate or root CA.
Investigation Findings
----------------------
1. Certificate Chain Structure
The certificate chain for router.hereapi.com is structured as follows:router.hereapi.com ← Leaf certificate (expires Mar 2027) └── GlobalSign RSA OV SSL CA 2018 ← Intermediate CA (expires Nov 2028) └── GlobalSign Root CA - R3 ← Root CA (expires Mar 2029)
GlobalSign Root CA-R3 is a publicly trusted root valid until March 18, 2029.
GlobalSign RSA OV SSL CA 2018 is an intermediate CA valid until November 21, 2028.
2. TLS Handshake Behavior
The server sends only the leaf and intermediate certificates during the TLS handshake.
The root CA is not included and must be obtained from GlobalSign or another trusted repository.
3. Multiple GlobalSign Roots
GlobalSign maintains several root CAs (e.g., R1, R2, R3), each with different validity periods and trust paths.
To correctly validate the HERE API chain, customers must use GlobalSign Root CA-R3, not R1 or R2.
Resolution
----------
To correctly validate the HERE API certificate chain and address concerns about short leaf certificate validity:
Extract the intermediate CA certificate directly from the live server using OpenSSL.
Download the correct GlobalSign Root CA-R3 certificate directly from GlobalSign and convert it to PEM format.
Use these certificates as trust anchors (intermediate and/or root) instead of pinning the short‑lived leaf certificate.
Implementation Steps
--------------------
1. Extract the Intermediate CA Certificate
------------------------------------------
Step 1: Verify how many certificates the server sendsopenssl s_client -connect router.hereapi.com:443 -showcerts 2>/dev/null < /dev/null \ | grep -c "BEGIN CERTIFICATE"
Expected output: 2 (leaf + intermediate only, root CA is not transmitted).
Step 2: Extract the intermediate certificate (index 2)openssl s_client -connect router.hereapi.com:443 -showcerts 2>/dev/null < /dev/null \ | awk '/-----BEGIN CERTIFICATE-----/{i++} i==2{print} /-----END CERTIFICATE-----/ && i==2{exit}' \ > globalsign_intermediate.pem
Step 3: Confirm path and verifyecho "Saved at: $(pwd)/globalsign_intermediate.pem"openssl x509 -in globalsign_intermediate.pem -noout -subject -dates
Expected output (simplified):
subject=CN=GlobalSign RSA OV SSL CA 2018
notAfter=Nov 21 00:00:00 2028 GMT.
2. Download the Root CA Certificate (GlobalSign Root CA-R3)
-----------------------------------------------------------
The root CA is not included in the TLS handshake and must be downloaded directly from GlobalSign. Ensure you use R3, not R1 or R2.
Step 4: Download Root CA R3curl -O https://secure.globalsign.com/cacert/root-r3.crt
Step 5: Convert from DER to PEMopenssl x509 -inform DER -in root-r3.crt -out globalsign_root_r3.pem
Step 6: Confirm path and verifyecho "Saved at: $(pwd)/globalsign_root_r3.pem"openssl x509 -in globalsign_root_r3.pem -noout -subject -dates
Expected output (simplified):
subject=OU=GlobalSign Root CA - R3, O=GlobalSign, CN=GlobalSign
notAfter=Mar 18 10:00:00 2029 GMT.
Step 7: Confirm it is self‑signed (root trust anchor)openssl x509 -in globalsign_root_r3.pem -noout -issuer -subject
Issuer and subject must be identical for a self‑signed root CA.
3. Validate the Full Chain
--------------------------
Step 8: Test TLS handshake using the root CAopenssl s_client -connect router.hereapi.com:443 -CAfile globalsign_root_r3.pem 2>&1 \ | grep -E "Verify return code|depth"
Expected result:
Verify return code: 0 (ok) — confirms that GlobalSign Root CA – R3 correctly validates the full chain down to the leaf.
Important Considerations
------------------------
Short Leaf Validity Is Expected
Due to CA/Browser Forum changes, public CAs are moving to significantly shorter TLS certificate lifetimes (roughly 199 days starting March 2026 and decreasing further by 2029). Short validity for leaf certificates is normal and improves security.
Do Not Pin Leaf Certificates
Customers should avoid pinning the leaf certificate, as frequent renewals will cause it to change regularly. Instead, anchor trust to the intermediate CA or the GlobalSign Root CA-R3.
Select the Correct GlobalSign Root
Using R1 or R2 instead of R3 may cause chain validation issues because those roots have different validity ranges and chains. Always use GlobalSign Root CA-R3 for HERE API endpoints that chain to this root.
Key Benefits
------------
Correct Chain Validation
Ensures that HERE API endpoints such as router.hereapi.com validate successfully against the correct GlobalSign root.
Resilience to Certificate Rotation
By trusting the intermediate and/or root rather than the leaf certificate, customers avoid breakages caused by short‑lived leaf certificate renewals.
Alignment with Industry Standards
The approach aligns with CA/Browser Forum best practices and upcoming TLS lifetime reductions, reducing operational risk as certificates rotate more frequently.