- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
08-11-2020 02:47 PM
If inbound SSL inspection when using Digicert certificate is not supported, what is the alternative. We have many web-servers using same wildcard cert used for GlobalProtect and wanted use this same certificate but it doesn't work. Is there any other mechanism to implement inbound SSL inspection.
08-11-2020 02:50 PM
Hi @raji_toor
What do you mean with not supported with digicert? What type (algorythms) of certificate do you have?
08-11-2020 04:24 PM
@Remo I think this is not the only KB i came across while to work this out https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClEZCA0
NOTE: Because SSL certificate providers such as Entrust, Verisign, Digicert, and GoDaddy do not sell CAs, they are not supported in SSL Decryption.
08-11-2020 11:40 PM
Hi @raji_toor
For SSL inbound decryption the servercertificates including your wildcardcertificate is supported. Only for SSL forward proxy you have to use a self signed certificate.
08-12-2020 08:02 AM
@Remo Its not working for me. certificate in use by GP
certificate on web-server
PA config
With above profile attached to the decryption rule
With no profile attached to the decryption rule
traffic from outside
08-12-2020 09:44 AM
Quote:
NOTE: Because SSL certificate providers such as Entrust, Verisign, Digicert, and GoDaddy do not sell CAs, they are not supported in SSL Decryption.
I think the way that it was intended was that SSL Forward Proxy (standard decryption) is not supported with SSL Certificate Providers because they DO NOT SELL A CA (Certificate Authority), in other words, they do not sell you a license to create certificates that look like they created the certificate, You would then have the ability to create SSL Certs from all of these providers (and maybe try to sell them).
SSL Inbound Decryption, where you are intercepting traffic to an internal server and therefore use that SSL Cert to be installed on the Firewall to "Impersonate" the internal server.. that can be a Certificate from any provider.. because in that scenario, no SSL Certs are being created.
I hope that makes a little more sense.
08-12-2020 12:54 PM
Hi @raji_toor
Now you need to start troubleshooting the connection. As you are using the same certificate already for globalprotect, this is not the reason for this issue. First check what ciphersuites and tls versions does the server offer for a tls connection. With a website like Qualys ssllabs - as you already know - you can check what the server does offer (for this test of course you need to disble decryption). Is the server behind the firewall a windows server? If yes, which version and do you have extended master secret enabled (is enabled by default)?
08-12-2020 03:25 PM
@Remo server supports a lot, and almost all are linux servers
TLSv1.0
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLSv1.1
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLSv1.2
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLSv1.3
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
Decryption profile allows for below
Atleast 3 of them are common between the profile and what server supports under TLS1.2
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
-----------------------------------
I also realized that inbound inspection broke for all the servers sitting behind F5 in DMZ. Even though F5 VIP is configured either for SSL offload or SSL pasthrough.
So i found a server which was not behind F5 and decryption worked.
08-12-2020 04:35 PM
Ok, now it is getting kind of strange. Mainly because it does not matter if the F5 is configured for offloading or passthrough...
So, this is at least how I would continue here:
08-13-2020 04:17 PM
@Remo Thanks for the pointers, it is is still not working and i think i can zero in on the issue as below. First decryption process is different when when performing inbound inspection vs forward proxy. With inbound we are only eaves dropping on the session and the ciphers need to match on both sides. Thanks to this KB that explains it better.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClV8CAK
So i started looking in packet captures as you suggested, and firewall shows drop for packets with this cipher.
Also i checked from the browser with both inspection disabled/enabled and found the same ciphers.
Although F5 or other servers that fail support other ciphers but they all seem to liken above more. Below is the cipher enum results for a server with inspection disabled, not behind F5 but it still failed.
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| TLSv1.1:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| TLSv1.2:
| ciphers:
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| compressors:
If i select 1.2 as the minimum protocol in decryption profile 3DES get grayed out. Which leads me to be believe "TLS_RSA_WITH_3DES_EDE_CBC_SHA" is not supported on firewall. So in all what i understand/ believe is that because ciphers need to match on both sides of firewall, which is not happening and is causing this issue. Do you think i am right at this conclusion and we need to fix on the server side ciphers that are supported.
08-14-2020 01:16 AM
Hi @raji_toor
Yes, I think you are right with this conclusion. But besides that I would recommend anyway to configure some stronger ciphersuites on the servers, you could give it a try with enabling 3DES in the decryption profile via CLI. I did not test it with an actual inbound decryption, but I was able to enable 3DES with TLS1.2 in CLI. On the WebUI then it does not even show 3DES enabled but in the configuration it is there.
08-14-2020 10:33 AM - edited 08-14-2020 10:34 AM
I was able to set ciphers for a test VIP on F5, And i enabled only 1 cipher which the F5-VIP had in server hello after disabling 1.3 on it.
Currently this F5 VIP supports single cipher, and it works with no inspection, tested from chrome. I can enable more ciphers too but i believe this should have worked. Below is with no inspection.
When i turn inspection on i get this in chrome.
Client hello ciphers
PA profile settings
ssl-inbound-proxy {
block-unsupported-version no;
block-unsupported-cipher no;
block-if-no-resource no;
block-if-hsm-unavailable no;
}
ssl-protocol-settings {
min-version tls1-2;
keyxchg-algo-rsa yes;
keyxchg-algo-dhe yes;
enc-algo-3des no;
enc-algo-rc4 no;
auth-algo-sha1 yes;
keyxchg-algo-ecdhe yes;
enc-algo-aes-128-cbc yes;
enc-algo-aes-256-cbc yes;
enc-algo-aes-128-gcm yes;
enc-algo-aes-256-gcm yes;
auth-algo-sha256 yes;
auth-algo-sha384 yes;
What do you suggest @Remo
08-14-2020 11:40 AM
I further enabled more ciphers on VIP and i still get cipher mismatch, while turning inspection off it works
With no inspection
TLSv1.2:
| ciphers:
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!