Global Protect Client certificate Auth Failure with Empty CN
64937
Created On 03/25/19 06:17 AM - Last Modified 05/25/21 00:43 AM
Symptom
Globalprotect Client certificate authentication fails even though the correct client certificate is installed on the client PC and the issuer is configured as "Trusted CA" on the Firewall.
The VPN connection will fail even though the intended certificate is picked up by Globalprotect client and sent to the server for Client certificate authentication if the Subject CN is empty on the client certificate.
The client side logs would show the below errors.
(T6560) 03/24/19 19:30:51:752 Info ( 736): Server cert query failed with error 12019 (T6560) 03/24/19 19:30:51:752 Debug( 905): PostRequest error code=2148074279(An unknown error occurred while processing the certificate.) (T6560) 03/24/19 19:30:51:752 Debug( 993): ERROR_WINHTTP_SECURE_FAILURE, clean m_pMachineCertCtx. RetryOn the firewall check the global counters for this connection.
Configure "Manage Filter" with the Source IP of the PC and Destination IP as the IP address of the Interface that terminates the Globalprotect Portal and Gateway.
If the client is in Internet then use the NATted Public IP of the Client PC.
Then enable the filter and run the below command once. The first output can be ignored.
> show counter global filter packet-filter yes delta yesAttempt to connect to the Portal and Gateway from the User PC that has the issue.
Wait for some time and run the below command again.
> show counter global filter packet-filter yes delta yesCheck the Global counters to see if the below counter is present.
proxy_client_cert_parse_error 167 3 warn proxy pktproc Number of ssl sessions with bad client cert proxy_decrypt_cert_validation_overall 167 3 info proxy pktproc Overall number of decrypted packet cert validationIf Packet Diag logs are taken for this connection with "flow basic" "ssl basic" and "proxy basic" features, the below logs can be seen in the packet diag output.
2019-03-24 20:07:58.853 -0700 debug: pan_proxy_cfg_client_cert_handler(pan_proxy_cfg.c:1244): receive client cert 2019-03-24 20:07:58.853 -0700 debug: pan_x509_parse_dn(pan_x509.c:519): didn't find common name 2019-03-24 20:07:58.853 -0700 debug: pan_x509_parse_tbs_certificate(pan_x509.c:1998): pan_x509_parse_dn() failed
Environment
- Global protect with Certificate Authentication
- Pan-OS 8.0
Cause
- Having an Empty CN on the Client Certificate is not supported by the PA firewall 8.0
- Starting with 8.1, there are no restriction on empty CN on the server side
Resolution
- Get the Client certificate re-issued from the CA server such that it contains a Subject CN.
- Then install this new certificate on the Client PC and test the connection again.
Additional Information
Firewall following RFC requirements . https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.6
RFC Details : "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical."
Firewall performs additional check if there is an empty CN/subject that the SAN field of the certificate is marked as "critical" extension. This is to make sure the certificate is according to the quoted RFC.
Here is some debug logs when SAN is not marked as "critical":
Firewall side flow basic, ssl basic, proxy basic : debug: pan_proxy_cfg_client_cert_handler(pan_proxy_cfg.c:1253): receive client cert debug: pan_x509_parse_tbs_certificate(pan_x509.c:2082): not before 210521151540Z not after 220521151540Z debug: pan_x509_parse_dn(pan_x509.c:531): didn't find common name debug: pan_x509_parse_tbs_certificate(pan_x509.c:2106): SSLVPN:Print the certificate hostid (null) debug: pan_x509_parse_tbs_certificate(pan_x509.c:2108): SSLVPN:Print the certificate username (null) debug: pan_x509_parse_ext_subject_alt_name(pan_x509.c:1382): subject alt name debug: pan_x509_parse_ext_subject_alt_name(pan_x509.c:1400): found subject alternative names @478 00000000: 82 0b 6d 61 63 68 69 6e 65 2e 6c 61 62 ..machin e.lab debug: pan_x509_parse_tbs_certificate(pan_x509.c:2175): parse tbs certificate missing subject but subject alternative name is not critical debug: pan_x509_parse_cert(pan_x509.c:2374): pan_asn1_tbs_certificate() failed debug: pan_x509_parse_certs_chain(pan_x509.c:2548): pan_x509_parse_cert() failed; error debug: pan_ssl_parse_client_cert_handshake(pan_ssl.c:2372): pan_x509_parse_certs_chain() failed Error: pan_proxy_cfg_client_cert_handler(pan_proxy_cfg.c:1292): failed to parse client cert Error: pan_proxy_offload_ssl_handshake_cb(pan_proxy_ssl.c:576): client cert callback() failed Error: pan_ssl_proxy_handle_rt_hs(pan_ssl_proxy.c:251): handshake callback failed: -3 Error: pan_ssl_proxy_parse_data(pan_ssl_proxy.c:621): pan_ssl_parse_record() failed
Firewall counters : proxy_ssl_invalid_cert 7 3 info proxy pktproc Number of ssl sessions using invalid certificate proxy_client_cert_parse_error 7 3 warn proxy pktproc Number of ssl sessions with bad client cert
GP logs: (T7008)Debug( 868): Found the cert [empty] issued by OpenSSL-CA9 sha1 hash is b4 fd 25 c7 a7 e6 ee ac 2e ef cd dd bd f5 e9 02 35 14 98 51 in machine store (T7008)Debug( 874): Finished searching machine store. (T7008)Debug(1016): PrepareRequest, m_pMachineCertCtx is 000001AF7749D0B0... (T7008)Debug(1024): WinHttpOpenRequest... (T7008)Debug( 442): CPanHTTPSession::PostRequest: WinHttpSendRequest... (T7008)Debug( 453): bResults=0, g_dwStatus = 00000000 (T7008)Debug( 456): SendRequest failed with error -2146893017 (T7008)Debug( 756): The length of the serialized string is 879. (T7008)Debug( 775): The encoded element has been serialized. (T7008)Debug( 786): SerializeServerCert(): wrote 879 of 879 bytes to file C:\WINDOWS\system32\config\systemprofile\AppData\Local\Palo Alto Networks\GlobalProtect\ServerCert.pan. (T7008)Debug(1043): PostRequest error code=2148074279(An unknown error occurred while processing the certificate.) (T7008)Debug(1132): ERROR_WINHTTP_SECURE_FAILURE, clean m_pMachineCertCtx. Retry
On 8.1 and later if you generate a certificate which has an empty subject (which is fine) and has SAN (which is fine), but SAN extension MUST be marked as "critical" for the cert to be by RFC.
If it isn't, PAN-OS would error out - which is, again, fine, because certificates shouldn't be made as such.