Configuration Articles

Featured Article
Overview The GlobalProtect prelogon connect method is a feature that enables GlobalProtect to authenticate the agent and establish the VPN tunnel to the GlobalProtect gateway using a pre-installed device certificate before the user has logged in. Because the tunnel is already established, domain scripts can be executed when the user logs are in, instead of using cached credentials. Prior to user login, there is no username associated with the traffic. Therefore, to enable the client system to access resources in the trust zone there must be a security policy created that matches the prelogon user. These policies should only allow access to basic services required to start up the system, such as DHCP, DNS, Active Directory (for example, to change an expired password), antivirus, and/or operating system update services. After the user logs in to the system and authenticates, the VPN tunnel is renamed to include the username so that user and group based policy can be enforced.   With pre-logon, when an agent connects to the portal for the first time, the end user must authenticate (either through an authentication profile or a certificate profile configured to validate a client certificate containing a username). After authentication succeeds, the portal pushes the client configuration to the agent along with a cookie that will be used for portal authentication to receive a configuration refresh. When a client system attempts to connect in pre-logon mode, it will use cookies to authenticate to the portal and receive its pre-logon client configuration. It will connect to the gateway specified in the configuration and authenticate using its device certificate (as specified in a certificate profile configured on the gateway) and establish the VPN tunnel.   Steps The Palo Alto Networks firewall is configured with a root certificate, the Root CA that signs the server certificate and the device certificate. Export the device (Machine) cert and the Root CA certificate to the individual device that will connect using GlobalProtect. The client can use their own PKI infrastructure to generate device certificates. In these type of scenarios, the firewall admin should import the Root CA signing these device certificates into the Palo Alto Networks firewalls.   Configure the certificates required for prelogon Go to Device > Certificate Management > Certificates > Device Certificate and select the "GP Machine Cert"(used for this example) device certificate: Click Export: Select Root CA and Export: Download the certs and install them onto their cert stores: For MAC OS X clients Open Keychain Access and go to the System keychains: Ensure that all applications have access to the private keys of the device and the Root CA certs: For Windows clients The correct way of importing certificates is either by GPO install or a manual certificate install. Below is an example for a Windows 7 device: Delete previous incorrect machine-certificate and root-CA-certificate on MMC Right click LOCAL-COMPUTER > Personal > Certificates, All Tasks > Import, Import the machine-certificate. Right click CURRENT-USER > Trusted Root Certification Authorities > Certificates, All Tasks > Import, Import the root-CA-certificate. Right click LOCAL-COMPUTER > Trusted Root Certification Authorities > Certificates, All Tasks > Import, Import the root-CA-certificate. Below are examples for installing the device certificate: Note: For more information about the MMC, see the TechNet library on the Microsoft website. Create a client Certificate Profile that includes the root certificate: Configure the portal as shown below: Enter values for Portal Configuration. The Portal Configuration does not require a client certificate, which was mandatory prior to PAN-OS 6.0 for the prelogon to work. On the Client Configuration tab, configure prelogon client configurations to use the CACR functionality: For both the client configurations, "Cookie authentication for config refresh" is chosen as the Authentication Modifier type. The Connect Method selected should be "pre-logon" and the "Use single sign-on" checkbox should be selected in both cases: Configure the GlobalProtect Gateway as shown below: Once the changes are committed, the configuration on the interfaces should reflect the GlobalProtect settings:   Prelogon client authentication The user has to connect to the portal for the first time to download the GlobalProtect client. The portal pushes the client configuration to the agent, along with a cookie that will be used for the portal authentication to receive a configuration refresh: When the user logs off from the client or when the clients' device finishes booting up, the clients' system attempts to connect in prelogon mode and uses cookies to authenticate to the portal and receive its prelogon client configuration. It will then connect to the gateway specified in the configuration, and authenticate using its device certificate (as specified in a certificate profile configured on the gateway) and establish the VPN tunnel. Shown below is a snapshot of when the user logs from their device. The device has been authenticated as a prelogon user: Prelogon logs on the the Palo Alto Networks firewall The firewall generates logs pertaining to the cookie based authentications when the sslvpn logs are set to the debug. The example below shows logs for the cookie based authentication for the prelogon user: When the end user logs into the device, if single-sign-on (SSO) is enabled in the client configuration, the username will immediately be reported to the gateway so that the tunnel can be renamed and user and group based policy can be enforced. If SSO is not enabled in the client configuration, or if SSO is no supported on the client system (for example, it is a Mac OS system) the users' credentials must be stored in the agent (the 'Remember Me" check box must be selected within the agent). The logs for the user authentication cookie are also generated as shown below: System logs for the preglogon functionality: The authentication type is cookie: System logs for the regular authentication: The authentication type is cookie:   owner: kprakash
View full article
‎07-30-2018 01:43 AM
64,244 Views
1 Reply
3 Likes
 What is GlobalProtect with On-Demand?   As the name says, on-demand (at user's will), the user has control over when to connect or disconnect from GlobalProtect. Once connected to GlobalProtect, the user will see a 'disconnect' option to disconnect when needed.   This document explains basic GlobalProtect configuration for on-demand with the following considerations:   Authentication - local database Same interface serving as portal and gateway. Root, intermediate and server certs are generated on PAN   1. Generate a root CA, intermediate CA and a server cert as explained in this document: https://live.paloaltonetworks.com/t5/1-Submit-and-Collaborate/Certificate-config-for-GP-SSL-TLS-Client-cert-profiles/ta-p/131592         2. Create an SSL/TLS profile under Device > Certificate Management > SSL/TLS service profile, referencing the above created 'server certificate'.   3. Create an authentication profile under Device > Authentication Profile > Add.   Name- Give a name to this authentication profile Type - Choose Local Database(You may choose ldap,radius etc depending on your requirement)   Advanced Tab > Allow List > Add - Select all (If you have groups, you may restrict it to required groups) Click OK to save.         4. Create a tunnel interface under Network > Interfaces >Tunnel. Give a tunnel number, virtual router and security zone. It is recommended to create a separate zone for VPN traffic as it gives better flexibility to create separate security rules for the VPN traffic.       Configure GlobalProtect Portal   5. Go to Network > GlobalProtect > Portals > Add. General Tab. Give a name to the portal and select the interface that serves as portal from the drop down.      6. Authentication Tab.   a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.   7. Agent Tab. Add a new client config. a. Authentication tab: Give any name to this client config Client certificate - leave it to none, this will only be needed if we want to push any client certificate to clients for authentication purpose. Save user credentials - Yes(default) (Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate that is selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '.     b. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups if needed)   Important! Gateways tab.  Under 'External gateways', click Add. Give any name to it. Address- Enter the IP address or FQDN which was referenced in the certificate Common Name(CN) or Subject Alternate Name(SAN) of step 1. In this example we enter 'gp.portal-gw01.local'        d. App tab. Under 'Connect-method' drop down, select 'On-demand (Manual user initiated connection)'.  Note: To change this GP setup from 'On-demand' to 'user-logon', just change the 'connect-method' from 'on-demand' to 'user-logon'.     e. Click OK to save. f. Under 'Trusted Root CA', select the root CA and intermediate CA. Also, select 'Install in Local root certificate store' to install these certificates in the client's local root certificate store after the client successfully connects to the portal for first time.   g. Click OK to save and close GP portal config.     Configure GlobalProtect Gateway   8.  Go to Network>GlobalProtect>Gateways>Add. General Tab. Give a name to the gateway and select the interface that serves as gateway from the drop down.    9. Authentication Tab. This is similar to step 6 but this is for gateway. a. Under SSL/TLS service profile, select the SSL/TLS profile created in step 2 from the drop-down. b. Client Authentication>Add. Give any name to it, leave the OS to 'any' unless you want to restrict it. Under authentication profile, select the auth profile created in Step 3. c. Click ok to save.     10. Agent Tab. a. Tunnel Settings. Check 'Tunnel mode' to enable tunnel mode and select the tunnel interface created in step 4 from the drop-down.  b. Enable IPSec. Check this box to enable IPSec, this is highly recommended. With this setting enabled, GP will always try to first connect over IPSec, if it fails then GP falls back to SSL.   c. Timeout settings - leave them to defaults. For any changes to this, refer to GP admin guide. d. Client settings   Click Add> Give a name to authentication override tab   -(Optional) Authentication override: Check the boxes for ' Generate cookie for authentication override' and 'Accept cookie for authentication override'. This cookie can be encrypted/decrypted using any certificate selected from the drop down of ' Certificate to Encrypt/Decrypt Cookie '. Note: If a certificate is selected here under portal, the same needs to be selected here under Gateway 'certificate to encrypt/decrypt cookie'.     e. User/User group tab. Leave the OS and User group to 'any' (You may restrict it to required groups if wanted).    Important! If a group is chosen from the drop-down, make sure that the GlobalProtect user is part of this group, if not the client will NOT receive IP address from gateway. Common issues here are when the user is identified by GlobalProtect as 'domain\user' but the firewall's userid may have it as 'fully qualified domain\user', in those cases make sure the group/user is shown identical at both places by overwriting domain field in user-identification>group mapping.      f. Network Settings.  Under the Ip-pool:     Very Important! The GlobalProtect gateway will be assigning IPs from this pool to clients. Specify the one or more IP pool ranges which DO NOT OVERLAP with any of the existing networks in the organization. Overlapping subnets can cause routing issues and network outages. (Optional but recommended) You can add a second IP pool range for backup which will be useful in cases where the user connects a wifi that is providing the same IP pool range as your primary IP pool.   g. Access Route. This defines which subnets can be reached by GP clients once they are connected to gateway. If left blank, it takes it as 0.0.0.0/0 ie all the traffic from GP client will be forced to go through GP tunnel. For split tunneling: Specify required internal subnets like 10.0.0.0/8, 192.168.x.0/24 etc so that GP client will use the tunnel to reach only these subnets. Anything outside these subnets will be accessed directly from the client's local network, th is is called split tunneling.   h. Click OK to save and close client settings. One more OK to save and close GP gateway settings.   11. Create a local username/password under Device>Local user database>users for testing. 12. Create security and NAT policies for the newly created VPN zone to give access appropriately. 13. Commit the changes.   To test on client machine   1. From the browser, go to https://gp.portal-gw01.local/ ie https://<portal-ip/fqdn> 2. Enter the credentials 3. Download the GlobalProtect client  4. In the GlobalProtect client, enter the Portal address and credentials, click connect.    
View full article
dreputi ‎06-18-2018 12:40 PM
20,988 Views
2 Replies
1 Like
Overview PAN-OS can decrypt and inspect inbound and outbound SSL connections going through the Palo Alto Networks firewall. SSL decryption can occur on interfaces in virtual wire, Layer 2 or Layer 3 mode by using the SSL rulebase to configure which traffic to decrypt. In particular, decryption can be based upon URL categories and source user and source/target addresses. Once traffic is decrypted, tunneled applications can be detected and controlled, and the decrypted data can be inspected for threats, URL filtering, file blocking, or data filtering. Decrypted traffic is never sent off the device.   Inbound SSL Decryption In the case of inbound traffic to an internal Web Server or device, the administrator imports a copy of the protected server’s certificate and key. When the SSL server certificate is loaded on the firewall, and a SSL decryption policy is configured for the inbound traffic, the device then decrypts and reads the traffic as it forwards it. No changes are made to the packet data, and the secure channel is from the client system to the internal server. The firewall can then detect malicious content and control applications running over this secure channel.   Outbound SSL Decryption (SSL Forward Proxy) In this case, the firewall proxies outbound SSL connections by intercepting outbound SSL requests and generating a certificate on the fly for the site the user wants to visit. The validity date on the PA-generated certificate is taken from the validity date on the real server certificate. The issuing authority of the PA-generated certificate is the Palo Alto Networks device. If the firewall’s certificate is not part of an existing hierarchy, or is not added to a client’s browser cache, then the client receives a warning when browsing to a secure site. If the real server certificate has been issued by an authority not trusted by the Palo Alto Networks firewall, then the decryption certificate is using a second “untrusted” Certificate Authority (CA) key to ensure the user is warned of any subsequent man-in-the-middle attacks.   To configure SSL decryption: Configure the firewall to handle traffic and place it in the network. Make sure the proper Certificate Authority (CA) is on the firewall. Configure SSL decryption rules. Enable SSL decryption notification page (optional). Commit changes and test decryption.   Steps 1. Configure the firewall to handle traffic and place it in the network Make sure the Palo Alto Networks firewall is already configured with working Interfaces (Virtual Wire, Layer 2 or Layer 3), Zones, Security Policy and already passing traffic.   2. Load or Generate a CA certificate on the Palo Alto Networks firewall A Certificate Authority (CA) is required to decrypt traffic properly by generating SSL certificates on the fly. Create a self-signed CA on the firewall or import a Subordinate CA (from your own PKI infrastructure). Select "Forward Trust Certificate" and "Forward Untrust Certificate" on one or more certificates to enable the firewall to decrypt traffic. Note: Because SSL Certificate providers like Entrust, Verisign, Digicert, and GoDaddy do not sell CAs, they are not supported in SSL Decryption.   From the firewall GUI, go to Device > Certificates. Load or generate a certificate for either inbound inspection or outbound (forward proxy) inspection.   Generating a Self-Signed Certificate Using a Self-Signed Certificate is recommended. For information on generating a Self-Signed Certificate, please see: How to Generate a New Self-Signed SSL Certificate   Generating and Importing a Certificate from Microsoft Certificate Server On the Microsoft Certificate Server for your organization, request an advanced certificate using certificate template “subordinate CA”. Download the cert. After downloading, export the certificate from the local certificate store. In IE, access the Internet Options dialog, select the Content tab, then click the Certificates button. The new certificate can be exported from the Personal certificates store. Select “Certificate Export Wizard”, export the private key, then select the format. Enter a passphrase and a file name and location for the resulting file. The certificate will be in a PFX format (PKCS #12). To extract the certificate, use this openSSL[4] command: openssl pkcs12 –in pfxfilename.pfx –out cert.pem –nokeys To extract the key, use this openSSL command: openssl pkcs12 –in pfxfilename.pfx –out keyfile.pem -nocerts Import the cert.pem file and keyfile.pem file into the Palo Alto Networks firewall on the Device tab > Certificates screen. In the case of a High Availability (HA) Pair, also load these files into the second Palo Alto Networks firewall, or copy the certificate and key via the High Availability widget on the dashboard.   The "Forward Trust" and "Forward Untrust" certificates:     Note: If using a self-signed CA, export the public CA Certificate from the firewall and install the certificate as a Trusted Root CA on each machine's browser to avoid Untrusted Certificate error messages inside your browser. Network administrators usually use GPO to push out this certificate to each workstation.   Examples of browser errors if the self-signed CA Certificate is not trusted:   Firefox untrusted CA error:   Chrome untrusted CA error:   Internet Explorer untrusted CA error:   3. Configure SSL Decryption Rules The network administrator determines what needs to be decrypted. A few suggestions for configuring SSL decryption rules: Implement rules in a phased approach. Start with specific rules for decryption, and monitor the typical number of SSL connections being decrypted by the device. Avoid decrypting the following URL categories, as users may consider this an invasion of privacy: Financial services Health and medicine Do not decrypt applications where the server requires client-side certificates (for identification). You can either block or allow connections requiring client authentication via the decryption profile feature introduced in PAN-OS 5.0.   An example of an outbound rulebase following suggestions for decryption. 4. Enable SSL Decryption Notification web page (optional) The user can be notified that their SSL connection will be decrypted using the response page found on the Device tab > Response Pages screen. Click "Disabled," check the "Enable SSL Opt-out Page" option and click OK.   The default SSL Opt-out page page can be exported, edited via an html editor, and imported to provide company-specific information: 5. Test Outbound Decryption To test outbound decryption: Make sure that in the outbound policy, the action is to alert for any viruses found. Also enable packet capture on that anti-virus security profile. Commit any changes made. On a PC internal to the firewall, go to www.eicar.org. In the top right corner: Click “Download anti-malware testfile." In the screen that appears, scroll to the bottom. Download the eicar test virus using http. Any of the these four files will be detected. Go to the Monitor tab > Threat log, and look for the log message that detects the eicar file. Click the green arrow in the column on the left to view the captured packets. Click the magnifying class in the far left column to see the log detail. Scroll to the bottom, and look for the field “Decrypted.” The session was not decrypted:   Go back to the www.eicar.org downloads page. This time use SSL enabled protocol HTTPS to download the test virus. Examine the Threat logs. The virus should have been detected, since the SSL connection was decrypted. A log message that shows Eicar was detected in web browsing on port 443 will be visible. View the packet capture (optional) by clicking the green arrow. To the left of that log entry, click the magnifying class. Scroll to the bottom. Under Flags, check to see that “Decrypted” is checked:   The virus was successfully detected in an SSL-encrypted session.   To test the “no-decrypt” rule, first determine what URLs fall into financial services, shopping, or health and medicine categories. For BrightCloud, go to http://www.brightcloud.com/testasite.aspx. For PAN-DB, use Palo Alto Networks URL Filtering - Test A Site , and enter a URL to see what the category is. Once web sites that are classified into categories that will not be decrypted are found, use a browser to go to those sites using https. There should be no certificate error when going to those sites. The web pages will be displayed properly. Traffic logs will show the sessions where application SSL traverses port 443, as expected.   To Test Inbound Decryption: Examine the traffic logs dated before enabling SSL for inbound decryption on the firewall. Look at traffic targeted for the internal servers. In those logs, the application detected should be “ssl" going over port 443. From a machine outside of the network, connect via SSL to a server in the DMZ. There will be no certificate errors, as the connection is not being proxied, just inspected. Examine the logs for this inbound connection. The applications will not be “ssl" but the actual applications found inside the SSL tunnel. Click the magnifying glass icon in those log entries to confirm decrypted connections.   Helpful CLI Commands: To see how many existing SSL decryption sessions are going through the device: > debug dataplane pool statistics | match proxy   Output from a PA-2050, where the first command shows 1024 available sessions, and the output of the second command shows five SSL sessions being decrypted (1024–1019=5): admin@test> debug dataplane pool statistics | match proxy [18] proxy session            :    1019/1024    0x7f00723f1ee0   To see the active sessions that have been decrypted: > show session all filter ssl-decrypt yes state active Maximum number of concurrent SSL decrypted sessions in PAN-OS 4.1, 5.0, 6.0 and 6.1 (both directions combined): Hardware SSL Decypted Session Limit VM-100 1,024 sessions VM-200 1,024 sessions VM-300 1,024 sessions PA-200 1,024 sessions PA-500 1,024 sessions PA-2020 1,024 sessions PA-2050 1,024 sessions PA-3020 7,936 sessions PA-3050 15,360 sessions PA-3060 15,360 sessions PA-4020 7,936 sessions PA-4050 23,808 sessions PA-4060 23,808 sessions PA-5020 15,872 sessions PA-5050 47,616 sessions PA-5060 90,112 sessions PA-7000-20G-NPC 131,072 sessions PA-7050 786,432 sessions   If the limit is reached, all new SSL sessions go through as undecrypted SSL. To drop any new SSL sessions beyond the session limit of the device: > set deviceconfig setting ssl-decrypt deny-setup-failure yes To check if there are any sessions hitting the limit of the device: > show counter global name proxy_flow_alloc_failure To view the SSL decryption certificate: > show system setting ssl-decrypt certificate Certificates for Global SSL Decryption CERT global trusted ssl-decryption x509 certificate version 2 cert algorithm 4 valid 150310210236Z -- 210522210236Z cert pki 1 subject: 172.16.77.1 issuer: 172.16.77.1 serial number(9) 00 b6 96 7e c9 99 1f a8  f7                      ...~.... . rsa key size 2048 siglen 2048 basic constraints extension CA 1 global untrusted ssl-decryption x509 certificate version 2 cert algorithm 4 valid 150310210236Z -- 210522210236Z cert pki 1 subject: 172.16.77.1 issuer: 172.16.77.1 serial number(9) 00 b6 96 7e c9 99 1f a8  f7                      ...~.... . rsa key size 2048 siglen 2048 basic constraints extension CA 1   To view SSL decryption settings: > show system setting ssl-decrypt setting vsys                          : vsys1 Forward Proxy Ready          : yes Inbound Proxy Ready          : no Disable ssl                  : no Disable ssl-decrypt          : no Notify user                  : no Proxy for URL                : no Wait for URL                  : no Block revoked Cert            : yes Block timeout Cert            : no Block unknown Cert            : no Cert Status Query Timeout    : 5 URL Category Query Timeout    : 5 Fwd proxy server cert's key size: 0 Use Cert Cache                : yes Verify CRL                    : no Verify OCSP                  : no CRL Status receive Timeout    : 5 OCSP Status receive Timeout  : 5 Block unknown Cert            : no For a list of resources about SSL Decryption, please refer to the following: SSL Decryption Quick Reference - Resources   For more information on supported Cipher Suites for SSL Decryption, please refer to the following: SSL Decryption Not Working Due to Unsupported Cipher Suites Limitations and Recommendations While Implementing SSL Decryption How to Identify Root Cause for SSL Decryption Failure Issues   Note: If anything else needs to be added to this document, please comment below.   owner: jdelio
View full article
nrice ‎01-25-2018 02:32 AM
866,839 Views
71 Replies
6 Likes
  Issue Different Certificate Profiles on GlobalProtect Portal and GlobalProtect Gateway which are using the same interface   Setup Certificate Profile #1: Cert-Prof-1 Certificate Profile #2: Cert-Prof-2   GlobalProtect Portal configured on ethernet1/3 (IP Address: x.x.x.x) using  Cert-Prof-1 GlobalProtect Gateway configured on same ethernet1/3 (IP Address: x.x.x.x) using  Cert-Prof-2   Outcome The Palo Alto Networks firewall will use "Cert-Prof-2" even for GlobalProtect Portal.   NOTE: In cases where Certificate Profiles are differently configured, connecting to GlobalProtect Portal might fail as the firewall will use the Gateway's Certificate Profile even for connection on GlobalProtect Portal.   Cause/Resolution When GlobalProtect Portal and Gateway are configured on the same interface and Certificate Profile is needed for Client Authentication on both GlobalProtect Portal and Gateway, please use the same Certificate Profile on both GlobalProtect Portal and Gateway as Dataplane (DP) on the Palo Alto Networks firewall uses only GlobalProtect Gateway's Certificate Profile for connections to both GlobalProtect Portal and Gateway.  
View full article
sahmed ‎01-09-2018 03:07 PM
3,461 Views
0 Replies
Issue Sometimes when you try to import a certificate to the Palo Alto Networks firewall you might see this error "Import of Certificate failed. Failed to extract certificate." In this example, we are using the certificate DigiCert High Assurance CA-3.     Cause The certificate format is not feasible with the Palo Alto Networks, which is why the error occured.     This is what the certifcate will look like in Notepad:   Resolution Save the certificate to the desktop. Open the cert and copy it to a file and, while saving, use the option "Base-64 encoded C.509 (.CER) format." If you open the new cert in notepad it should look clean. Re-import the new certificate and it should be successful.   What it looks like in notepad after exporting. After the Cert is imported:
View full article
achalla ‎12-18-2017 02:45 PM
12,988 Views
5 Replies
1 Like
Overview This document describes the steps to properly generate and apply certificates for a scenario involving multiple GlobalProtect Gateways managed by a single GlobalProtect Portal.   Steps Check licenses. Device hosting the portal should have a portal and gateway license.All the gateways managed by the portal need to have a gateway license. Generate and install certificates Generate a root Certificate Authority (CA) certificate on the Palo Alto Networks device which will host the portal. (On PAN-OS 4.0.x and 4.1.x go to Device > Certificates. On PAN-OS 5.0.x go to Device > Certificate Management > Certificates.) Export the generated root CA certificate Import the certificate to the Palo Alto Networks device which is hosting the external GlobalProtect Gateway. The generated root CA certificate must be imported to all external GlobalProtect Gateways. In this example, there are 2 GlobalProtect Gateways. First external GlobalProtect Gateway certificate. This certificate should be signed by the imported root CA certificate. The Common Name can be either IP or FQDN. Second External GlobalProtect Gateway certificate. This certificate should also be signed by the imported root CA certificate. The Common Name can be either IP or FQDN. Configure the GlobalProtect Portal (Network > GlobalProtect > Portals). Configure the Portal Configuration tab. For this example, the same certificate is being used for the GlobalProtect Portal and the first external GlobalProtect Gateway. Note: The "Satellite Configuration" tab shown in the screenshot below is not available before PAN-OS 5.0. Configure the Client Configuration tab Important: Only FQDNs associated with the gateway IP addresses can be entered under the list of External Gateways. If IP addresses for the gateways are entered, the following errors would show up in the PANGPS logs: Make sure the root CA certificate is added under Trusted Root CA: Configuration of the first external GlobalProtect Gateway: Configuration of the second external GlobalProtect Gateway:   See also How to Configure GlobalProtect GlobalProtect Configuration Tech Note   owner: sraghunandan
View full article
sraghunandan ‎12-08-2017 03:51 AM
9,678 Views
0 Replies
1 Like
This article can still be used as a reference but I strongly recommend to check out the newer versions out there specifically created to cover newer PAN-OS versions :   Basic-GlobalProtect-Configuration-with-Pre-logon   Overview This document describes how to configure GlobalProtect SSO with the Pre-Logon access method using self-signed certificates.   Steps The example configuration below is for one portal and one gateway residing on the same Palo Alto Networks device but can be expanded to reflect multiple gateways. Local Database authentication is used for this example but other authentication methods (LDAP, Kerberos, Radius, etc.) can be applied. Generate the root Certificate Authority (CA) certificate on the Palo Alto Networks device. This will be used to sign the server certificates for for both GlobalProtect Portal and Gateway, as well as the machine certificate that will be deployed to the client machines. Generate the server and machine certificates. Each certificate should be signed by the CA certificate created in Step 1. Device certificates associated with GlobalProtect should appear as follows: Create a Certificate Profile. This will be used to confirm machine certificate validity when cross-checking with the CA Certificate. Make sure to select the CA Certificate when adding 'CA Certificates'. Create your GP Portal as follows: Under Portal Configuration, configure the network and authentication settings. Select the server certificate generated in Step 3 above. For Certificate Profile, select the profile created in Step 4. Under Client Configuration, create a config file. This will be pushed to GlobalProtect clients during initial connection and rediscover network attempts. Configure the pre-logon client config with pre-logon access method. Configure another config with 'any' user so that all users including pre-logon will get the same config. In the Trusted Root CA section, add the root CA created in Step 1. This certificate will be pushed out to the connecting agents. A sample GlobalProtect Gateway configuration is shown below. Make sure to use the same server certificate and certificate profile used in the GlobalProtect Portal configuration. The image below shows a GlobalProtect Gateway configuration that terminates users to tunnel.1 (L3-Trust Zone) and uses the 192.168.200.0/24 scope with access route only to the Internal Trust Network (192.168.144.0/24) Next step is to export the machine certificate which will then be added to the trusted certificate store on the local computer. Use the PKCS12 file format and provide a passphrase. On the client machine, import the previously exported machine certificate. The image below demonstrates the use of the MMC certificate snap in for the local computer. This will execute the Certificate Import Wizard. Follow the steps to complete the import. The certificate for this example was exported in pkcs12 file format. Make sure to confirm the correct cert is detected. Install the certificate into the local computer personal certificate store and then confirm the installation. Here, syslog indicates the initial connection with the agent using the user credentials to successfully connect. Subsequently, log off the machine and verify that the machine is still able to make a successful connection to both GlobalProtect Portal and Gateway as a 'pre-logon' user with the machine certificate validated by the CA certificate.   owner: rkalugdan
View full article
gswcowboy ‎11-22-2017 05:22 AM
43,242 Views
4 Replies
1 Like
Overview This document describes the steps to configure GlobalProtect for authentication using certificates only, without the user being prompted for login.   Steps Create the certificate profile under Device > Certificate Management > Certificate Profile. Make sure Username Field is set to 'Subject' and the grey area to the right of it shows 'common-name'. Add the root CA under CA Certificates. Certificate Profile The image below shows the certificates created: Certificates Configure the GlobalProtect Gateway. Set Authentication Profile to None and select the certificate profile set to the one created in Step 1 above. GlobalProtect Gateway Configure the GlobalProtect Portal Set the Authentication Profile set to None. Select the Client Certificate and Certificate Profile. Note: Having the firewall generate a Client Certificate assumes that the Certificate infrastructure is set up on the network to support that client certificate.  Alternatively, a client cert may not be necessary and may also not be advisable in a multi-user environment.  It may better to use a certificate profile with the CA which will be used to sign each user's certificate, so that each user can and will receive a unique certificate from the CA. GlobalProtect Portal In the Client Configuration tab, disable SSO. Install the root and the client certificates in the machine local store of the client PC. Note: When exporting the client machine certificate from the Palo Alto Networks device, it needs to be in PKCS12 format. Install the client certificate in the user personal store. In the GlobalProtect client, there is no need to enter the Username and Password: Commit the configuration on the firewall. The GlobalProtect client will automatically connect to the gateway. The remote users for the Gateway will show up as the client certificate logging in. owner: pvermuri
View full article
pvemuri ‎11-21-2017 05:50 AM
33,705 Views
7 Replies
Overview This document describes the CLI commands for adding/removing URLs to/from the SSL-exclude-list for exclusion from the SSL decryption.   Details For example, if there is a policy to decrypt sessions for the category "shopping", but the wish is to exclude and not decrypt sessions to a site categorized as shopping (such as www.amazon.com), the single URL can be excluded by entering the following commands: > configure # set shared ssl-decrypt ssl-exclude-cert www.amazon.com # commit   The result will create an exclude rule for a single URL. The browser may need to be refreshed after adding the exclusion rule to have it recognize the actual server certificate, as opposed to the self-signed certificate from the Palo Alto Networks device.   The command configuration mode command, show shared ssl-decrypt , will display the entries in the exclude cache: # show shared ssl-decrypt ssl-decrypt {   ssl-exclude-cert [ www.amazon.com www.yahoo.com];   Note: In the event that adding these entries traffic is still reflected as decrypted in the traffic logs after making the above changes, it may be required to clear the SSL Decryption certificate cache to enforce the change. > debug dataplane reset ssl-decrypt certificate-cache   To revert, run the following commands: > configure # delete shared ssl-decrypt ssl-exclude-cert www.amazon.com # commit   owner: hmistry
View full article
nrice ‎11-10-2017 04:16 AM
21,082 Views
3 Replies
2 Likes
Please see the Apple support article at https://support.apple.com/en-us/HT207828 for the source of this information.   In summary, these releases have the following requirements:   Removes support for TLS connections using SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates.  Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0.  Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy. Note: If the SSL/TLS Service Profile for the GlobalProtect Portal and Gateway support a maximum TLS version of 1.1, then either an iOS 11 nor a Mac OS X 10.13 system will succeed in establishing a connection. Once the configuration is committed with the maximum version set to 1.2 or to "max:, then the GlobalProtect agent will succeed.   Changes coming with iOS 11 Security iOS 11, tvOS 11, and Mac OS High Sierra include the following changes to TLS connections: Removes support for TLS connections using   SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates. Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0.  Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy. Changes coming with Mac OS High Sierra Security macOS High Sierra, tvOS 11, and iOS 11 include the following changes to TLS connections: Removes support for TLS connections using SHA-1 certificates. Administrators of TLS services should update their services to use SHA-2 certificates. Removes trust from certificates that use RSA key sizes smaller than 2048 bits across all TLS connections. Uses TLS 1.2 as the default for EAP-TLS negotiation. You can change this default setting with a configuration profile. Older clients might still need 1.0.  Authentication based on client certificates requires the server to support TLS 1.2 with cipher suites that are compatible with forward secrecy.  
View full article
jjosephs ‎10-25-2017 01:30 PM
17,780 Views
0 Replies
1 Like
This document descibes the basics of configuring certificates in GlobalProtect setup. Please note that there can be other ways to deploy certificates for GlobalProtect which are not covered in this document.   A. SSL/TLS service profile -  Specifies Portal/gateway server cert, every portal/gateway needs one. B. Certificate profile(if any) - Used by portal/gateway to request client/machine certificate C. Installing client/machine cert in end client   A. SSL/TLS service profile In the context of GlobalProtect, this profile is used to specify GlobalProtect portal/gateway's "server certificate" and the SSL/TLS "protocol version range". If same interface serves as both portal and gateway, you can use the same SSL/TLS profile for both portal/gateway. If portal/gateway are served through different interfaces, you can use same SSL/TLS profile as long as the certificate includes both portal/gateway IPs/FQDNs in its Subject Alternate Name(SAN), if not, create different profiles for portals and gateways as needed.   The pre-requisite to create SSL/TLS profile is to either generate/import the portal/gateway "server certificate" and its chain To import a certificate generated externally, navigate to Device>Certificate Management>Certificates and click on 'import' at the bottom. To generate a certificate on the firewall, navigate to Device>Certificate Management>Certificates and click on 'generate' at the bottom.   If the server cert is signed by a well-known third-party CA or by an internal PKI server 1. Import the Root CA (private key is optional) 2. Import intermediate CAs if any (private key is optional) 3. Import the server cert signed by the above CAs "with" private key.   IMPORTANT! If subj alt name(SAN) does not exist in this cert: This cert's common name(CN) 'must' match the portal/gateway's IP or FQDN . If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be one of the entries in that SAN list. In this case the CN can be anything, it does not matter since only SAN will be used to match IP/FQDN. Should not be of type CA. It must be of type end-entity. As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. Eg. if portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and if the certificate references the fqdn 'vpn.xyz.com', then the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.   4. SSL/TLS profile (Location: Device>Certificate Management>SSL/TLS Service Profile)     -Name  - Give any name for this profile     -Certificate - Reference the server cert from step 3     -Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server   5. Reference this SSL/TLS profile in portal/gateway as needed.   If the server cert needs to be generated on the Palo Alto Networks  firewall 1. Generate a root cert with common name of any unique value. (other than IP or FQDN of portal/gateway)   (Location: Device>Certificate Management>Certificates click Generate at the bottom of the screen)   2. (optional) Generate a intermediate cert signed by above root cert. Specify its common name as any unique value. (other than IP or FQDN of portal/gateway)   3. Generate a sever cert signed by the above intermediate cert. a. This cert's common name 'must' match the portal/gateway's IP or FQDN if subj alt name(SAN) does not exist in this cert. In PAN firewalls, SAN can be created under the optional 'certificate attributes' of type 'hostname', 'IP' or 'email'. b. If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be present in that SAN list. c. Should not be a CA. d. As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. For example. if the portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and the certificate references the fqdn 'vpn.xyz.com', the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.        4. SSL/TLS profile (Location: Device>Certificate Management>SSL/TLS Service Profile)     Name  - Give any name for this profile     Certificate - Reference the server cert from step 3     Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server    5. Reference this SSL/TLS profile in portal/gateway as needed.   B. Certificate Profile (Location: Device>Certificate Management>Certificate Profile) Certificate profile specifies a list of CAs and Intermediate CAs. When this certificate profile is applied to the config, the portal/gateway will send a client certificate request to the client to request for a client/machine cert signed by the CA/intermediate CA specified in the cert profile. It is recommended to place both the root and intermediate CAs in this profile, instead of just root CA.    IMPORTANT! -Client certificate refers to user cert, it can be used for 'user-logon'/'on-demand' connect methods. Used to authenticate a user. -Machine certificate refers to device cert, it can be used for 'pre-logon' connect method. This is used to authenticate a device, not a user.   1. Import the "Root CA" that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key) 2. Import the "intermediate CAs" if any that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key) 3. Go to Device > Certificate Management > Certificate Profile, click Add. 4. Give a name to the profile. 5. Add the root and intermediate CAs from Step 1 & 2.   6. Note: Username field by default is set to 'None', in a typical setup where username is pulled from LDAP/RADIUS authentication, you can leave this to none. On the other hand, if certificates are the only method of authentication, that is, if you do not have RADIUS/LDAP for portal/gateway authentication then you must change username field from none to 'Subj' or 'Subj Alt' to extract username from the client certificate common name or email/principal name. Failing to do this will result in a commit failure. 7. (optional) Check CRL or OCSP if the portal/gateway needs to verify the client/machine cert's revocation status using CRL or OCSP. Please use this with caution as it can result in clients failing to connect if used in conjunction with 'Block session if certificate status is unknown'.   8. Reference this certificate profile portal/gateway as needed.   C. Installing client/machine cert in end client   When importing a client/machine certificate, import it in PKCS format which will contain its private key.   Windows -  1. Click Start>Run, type mmc to open Microsoft certificate management console. 2. Go to File > Add/Remove Snap-in:     IMPORTANT! 3. Click Certificates>Add and select one or both of the below:   a. To add client(user) certificate, select 'My user Account'. This is used for 'user-logon' and 'on-demand' since it authenticates a user. b. To add machine(device) certificate, select 'Computer Account'. This is used for 'pre-logon' as it authenticates a machine.           4. Import client/machine certificate into mmc. a. If you are importing client certificate, import it to 'Personal' Folder under 'My user account' b. If you are importing machine certificarte, import it to 'Personal' Folder under 'Computer Account'       5. Similarly import the Root CA in the 'Trusted Root Certificate Authorities and Intermediate CAs(if any) in the 'Intermediate Certification Authorities'     IMPORTANT! 6. Once imported, double click the imported client/machine certificate to make sure  a. It has private key b. Its certificate chain is full upto its root CA. If the chain is missing root CA or intermediate CA, import them to their respective folders as explained in Step 5.         7. At this point, the certificates are imported on the client, so you can close the mmc console without saving it.
View full article
dreputi ‎02-13-2017 11:46 AM
55,056 Views
8 Replies
3 Likes
Overview PAN-OS 6.0 introduced the ability to use certificates for IKE authentication. This document describes how to configure IKE authentication using self-signed certificates on a pair of Palo Alto Networks firewalls running PAN-OS 6.0.   Steps Generate a CA (Certificate Authority) certificate on one of the Palo Alto Networks firewalls. This certificate will be used to sign the client certificates for the authentication. Export the CA certificate: Then import it into the peer firewall: Now generate on a client certificate on both firewalls and sign each one with the imported CA certificate. PA-3000 Series: PA-2000 Series: Create a Certificate Profile on both firewalls and add the CA certificate, as shown in the following example: Create an IKE gateway on each firewall and select Certificate for the Authentication setting. In the following example, "Distinguished Name" (DN) is used as identification. The DN is the same as the Common Name of the certificate. PA-3000 Series: PA-2000 Series: Create an ipsec tunnel on both firewalls: Send traffic through the vpn tunnel to verify that it comes up. PA-3000 Series: PA-2000 Series:   owner: rvanderveken
View full article
rvanderveken ‎09-09-2015 06:05 PM
35,354 Views
3 Replies
Issue By default, the WildFire WF-500 WildFire appliance will use the management interface IP address when creating the certificate used for the firewalls connecting to it. This can be an issue if a Fully Qualified Domain Name (FQDN) is desired instead of the IP address.   Resolution To configure the FQDN and regenerate the certificate on a WF-500 WildFire appliance, enter the following commands: > configure # set deviceconfig system hostname your-wf-500-hostname # set deviceconfig system domain example.com # commit   Once the commit is finished, the certificate will be generated with both the FQDN specified (your-wf-500-hostname.example.com) and the IP address. Thus, a connection to either can be made successfully.   owner: pmak
View full article
pmak ‎09-04-2015 04:34 AM
2,932 Views
0 Replies
In some situations, you may want to restrict or prevent access to certain encrypted websites based on their Certificate Authority (CA). The CA itself may have been compromised so you want act immediately, or you no longer trust certificates issued by a particular CA.   You can control access manually on an individual client by deleting the certs in question from the list of browsers' Trusted Root CAs, but the manual process can be tedious and it's relatively easy to bypass these controls. Further, browsers such as Firefox use their own certificate repository, adding to the overall complexity of making sure all types of browsers are addressed.   As of PAN-OS v5.0.x, you can view the contents of the installed cert repository and disable Root CAs that are no longer trusted. This  feature minimally requires PAN-OS v5.0.x and enabling SSL-Decryption. Refer to SSL Forward Proxy (Man in the Middle) .   To view the list of certificates, go to Device > Certificate Management > Certificates:   Steps To restrict access to all sites signed by a particular CA: Enable Forward Proxy.  Refer to the Decryption Policies section in the Palo Alto Networks Administrator's Guide Release 5.0 (English). Though a single certificate can be used for both Forward Trust and Forward Untrust, creating a separate certificate specifically for Untrust (which must be generated as a CA) allows for easy differentiation of a valid certificate/trust error as the Palo Alto Networks device proxies the secure session: Verify the CA to be blocked, keeping in mind that doing so blocks access to all sites issued by this CA.   An easy way to verify the issuer of the cert is by using a browser to visit the site directly, without decryption and viewing the cert properties: Note: This example shows a legitimate and trusted root CA which would typically never be disabled--the example's for demonstration purposes only.   In the example, the certificate was issued by DigiCert High Assurance CA-3, a subordinate CA. Intermediate CAs are not installed into the Palo Alto certificate repository, as presenting a complete/valid chain is typically the responsibility of the hosting server. The top-most CA within the Certificate Hierarchy would need to be disabled, in this example, GTE CyberTrust Global Root. At this point, the Common Name (CN) of the cert is known, though to ensure the correct CA is disabled, it is best to view the Root Certificate directly. Compare the serial number with that of the certificate installed on the Palo Alto Networks device, as multiple CAs with similar names may be installed. Using Firefox, highlight the Root CA directly and scroll through the list of Certificate Fields to view the serial number.   If using Internet Explorer or Chrome (which shares the Windows Certificate Repository), view the Certification Path of the issued cert, highlight the Root CA (View Certificate), then scroll through the Certificate Details for the serial number:   Go to Device > Certificate Management > Certificates, search for the CN of the cert, highlight, then export to compare against the cert exported directly via the website/browser: Upon export, open the cert/view Certificate Details and compare the serial number with that of the site/browser exported CA: After confirming a match of servial numbers, highlight the certificate and disable: Next, go to Objects > Security Profiles > Decryption Profile and create a decryption profile. Below is a simple example to block sessions with untrusted issuers. Click OK. Go to Policies > Security > Decryption and associate the Decryption Profile with the Decryption Policy: Commit the configuration. Certificates for various sites issued by the disabled CA may have been previously cached, resulting in users bypassing the new Decryption Profile altogether. Enter the command > show system setting ssl-decrypt certificate-cache If sites are bypassing the block policy, delete the cert cache via the CLI: > debug dataplane reset ssl-decrypt certificate-cache Clearing this cache deletes all cached certs, and requires accessing sites again to repopulate. Verify intended sites are blocked. An initial certificate error is displayed, followed by (upon continuing) a block page: As mentioned in Step 2, viewing the certificate properties shows that the issuing cert is the 'Untrust' cert (if created), providing further validation that the session was intercepted and untrusted by the Palo Alto Networks device: To roll back changes, go to Device > Certificate Management > Certificates, search for the CN of the disabled cert, re-enable, and commit the configuration.   owner: bryan
View full article
bryan ‎08-25-2015 10:50 PM
9,506 Views
1 Reply
Issue After configuring SSL decryption Mozilla Firefox shows certificate error: Error: (Error code: sec_error_untrusted_issuer) See the image below for an example of this error message: Cause This occurs because Mozilla Firefox uses different certificate repositories than other browsers such as Internet Explorer (IE) and Google Chrome. Resolution To resolve the certificate error, import the root certificate used for the SSL decryption to the following location: Mozilla > Options > View Certificates > Authorities and click on Import. This will import the root certificate used for the SSL decryption, as shown below: Once the certificate has been imported verify the 'Edit trust settings'. Make sure the following options have been selected: Go to Options > Advanced > Certificates > View Certificates and select the certificate that was imported and select 'Edit Trust'. In the example below, the certificate selected is 172.16.105.1: owner: hshah
View full article
hshah ‎07-21-2014 06:05 AM
23,520 Views
4 Replies
1 Like
Overview This document describes the configuration steps that will restrict GlobalProtect access for only certified devices. Details This will prevent GlobalProtect users from using unknown devices. The following is a list of requirements that will ensure that the appropriate Windows, Mac OS X, iOS, and Android devices can establish a VPN with GlobalProtect: The Palo Alto Networks firewall’s SSL certificate must have a fully qualified domain-name that resolves to the IP address of the GlobalProtect Portal and Gateway to satisfy Apple iOS requirements. (The user can specify an IP address in the Common Name field if iOS is not included in the list of supported devices). This certificate will be used to sign a machine certificate The portal will not distribute this certificate The GlobalProtect Portal and Gateway will use the firewall's SSL certificate, which then requires a device to present the issued machine certificate for verification. The machine certificate certifies the device. A user must still properly authenticate in order to establish the tunnel. Go to Device > Certificate Management > Certificates This is the firewall’s primary SSL certificate. When this certificate was created, the fully qualified domain-name was entered in the Common Name field and the Certificate Authority box was checked. It is necessary that a FQDN is presented by the firewall when an iOS device connects to it. The certificate shown below has been selected for other functions, but for this topic, it is going to be used to sign the machine certificate. Create Machine Certificate Go to Device > Certificate Management > Certificates, click Generate to create a new certificate. This is the machine certificate that will be provided to all devices that can use it for GlobalProtect. Notice this certificate is signed by the previously illustrated CA certificate.  Any title or information can be entered under Certificate Name and Common Name fields. Below is an example of what the Certificate Information would look like viewing it after it has been created: Export Machine Certificate Select the PKCS12 file format and enter a password to encrypt this key. This certificate needs to be installed on a device before it first attempts a GlobalProtect connection: Create Certificate Profile The firewall's SSL certificate needs to be added to a Certificate Profile so that the profile can be specified in the GlobalProtect Gateway: Go to Device > GlobalProtect > Gateway and specify certificates for the Gateway. The firewall's SSL certificate is selected for the Server Certificate field, as shown below: Go to Device > GlobalProtect > Portal > Portal Configuration The Client Certificate field is used to distribute the machine certificate to a GlobalProtect platform, which means that any user who authenticates successfully from any device would receive this certificate. Leave this blank to prevent this from happening. The Certificate Profile field is used to specify the CA certificate that signs the certificate that the device must present when one goes to the GlobalProtect client software download page on the firewall. The GlobalProtect agent will also present a machine certificate when it connects to the Portal to retrieve updates. The user may want use the certificate profile created earlier once they have this setup working. Go to Device > GlobalProtect > Portal > Client Configuration In the Portal dialogue window, select Client Configuration and then open a configuration profile that is listed there. The following dialogue window is displayed. The Client Certificate field specifies the certificate that the GlobalProtect must present to the Gateway to certify the connecting device. This certificate needs to be signed by the Server Certificate that the Gateway is using. This is the same certificate that was exported in the PKCS12 format in the Export Machine Certificate section above. Once these settings have been committed, a user that authenticates successfully may only do so from a device that has the required machine certificate. owner: jjosephs
View full article
jjosephs ‎07-13-2014 05:34 PM
15,765 Views
1 Reply
1 Like
Overview The GlobalProtect configuration has the ability to authenticate users based on username/password, or on certificates. When using certificates to connect, it is a valuable benefit to use an OCSP server to check for revocation status of the certificate, so that the users are denied access if the certificate is revoked. This setup is beneficial when it is used for consultants, as they are allowed access to some projects for a period of time and than the access is revoked. Details Palo Alto Networks devices have the option to generate certificates for these types of users, and if the OCSP responder is configured on the device it allows the capability to revoke access, if needed. Because of this scenario, an OCSP responder is needed on the Palo Alto Networks firewall. To setup the OCSP go to, Device > Certificate Management > OCSP Responder and click Add. Enter a name for the OCSP Responder and use the IP address of the firewall as the the Host Name. As soon as the OCSP Responder is configured and committed, it is now possible to generate certificates on the firewall that are using the OCSP Responder to check the revocation status. To create certificates go to Device > Certificate Management > Certificates and click Generate. While creating new certificates be sure to use the OCSP Responder that is filed. This allows the connections that are authenticated initiated from the user, and holds the certificates that are checked with the OCSP server. To create a Certificate Profile for the VPN users, which will be verifying the revocation status with the OCSP, go to Device > Certificate Management > Certificate Profile. Specify the parameters for the username (in this case is the subject), the CA that signs the certificates and the OCSP URL. Note: Make sure to enable the usage of OCSP, CRL can also be enabled, but be aware that the OCSP will have precedence, because it is more reliable than the CRL. In the GlobalProtect Portal configuration the user authentication should be performed based on the Client Certificate Profile. To setup go to Network > GlobalProtect > Portals, click Add and select Portal Configuration: To perform the same steps for the GlobalProtect Gateway, go to Network > GlobalProtect, click Add and select the General tab as shown below: The users can login using certificates, which are validated using the OCSP. If access for user is no longer needed, revoke the certificate. To revoke the certificate, go to Device > Certificate Management > Certificates and select the certificate, click on the Revoke button. After the revoke, the status of the certificate will change from green "valid" to red "revoked" as shown in the example below: From the CLI, check the revocation status of the issued certificate for the specific OCSP (or for all) by using the command below: > debug sslmgr view ocsp all Current time is: Thu Apr 3 21:49:46 2014 Count Serial Number(HEX) Status      Next Update               Revocation Time Reason         Issuer Name  Hash   OCSP Responder URL ----  ------------------ --------    ------------------------  ------------------------  -----------  ----------------------- [ 1]  10                 revoked     Apr 04 21:41:39 2014 GMT  Apr 03 21:44:54 2014 GMT  7ccb1b43     http://10.193.17.2/CA/ocsp [ 2]  0D                 valid       Apr 03 22:41:39 2014 GM                             df89db2d     http://10.193.17.2/CA/ocsp When a user tries to login with a revoked certificate the firewall will check with the OCSP and deny access. This can be verified by the sslmgr.log, see the examples below: 2014-04-03 23:47:41.537 +0200 debug: sslmgr_check_status(sslmgr_main.c:655): [0] start checking OCSP, status for certificate chain, num: 3; block unknown: no; from DP: yes 2014-04-03 23:47:41.537 +0200 [OCSP] URL http://10.193.17.2/CA/ocsp  serialno: 0D 2014-04-03 23:47:41.538 +0200 [OCSP] URL http://10.193.17.2/CA/ocsp  serialno: 10 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 2, URI: (null) 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2000): [0] No AIA URL, skip checking OCSP for depth 2. 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 1, URI: http://10.193.17.2/CA/ocsp 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2045): [0] OCSP check result is 'valid' for level 1 per cache 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 0, URI: http://10.193.17.2/CA/ocsp 2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2045): [0] OCSP check result is 'revoked' for level 0 per cache 2014-04-03 23:47:41.538 +0200 debug: sslmgr_check_status(sslmgr_main.c:709): [0] OCSP check result is 'revoked', depth 0 2014-04-03 23:47:41.539 +0200 debug: sslmgr_check_status(sslmgr_main.c:915): [0] final status: revoked; reason: ; depth: 0; BY OCSP 2014-04-03 23:47:41.539 +0200 Send cookie:5 session:0 status:4 to DP owner: ialeksov
View full article
ialeksov ‎04-23-2014 02:35 PM
11,170 Views
8 Replies
1 Like
Overview Certificate Revocation List (CRL) is a list of certificates (or more specifically, a list of serial numbers for certificates) that have been revoked. Entities that present any revoked certificates should not be trusted. The Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. OCSP is described in RFC 6960 and is on the internet standards track. Both of these features are supported on the Palo Alto Networks firewall. Steps On the web UI: Go to Device > Setup > Session > Session Features Click Decryption Certificate Revocation Settings to bring up the following: Check Enable for CRL and/or OCSP On the CLI: Run the following CLI commands from configuration mode: To enable CRL # set deviceconfig setting ssl-decrypt crl yes To enable OCSP # set deviceconfig setting ssl-decrypt ocsp yes owner: sodhegba
View full article
sodhegba ‎12-26-2013 04:12 PM
10,142 Views
3 Replies
Details The decryption key is required when the source Palo Alto Networks firewall (from where the configuration file was exported), has a Master Key configured. The same key that was used on the source firewall must be used on the destination firewall when importing the configuration. The Master Key is used to encrypt private keys on the firewall, which includes the RSA key used to authenticate the server when logging into CLI and the private key used by the web server when logging into the web interface. Without the Master Key, when a configuration is exported from a firewall, the password is hashed and can be copied. The Master Key provides more security to those passwords. The Master Key is configured at Device > Master Key and Diagnostics: owner: sodhegba
View full article
sodhegba ‎09-17-2013 11:39 AM
5,481 Views
1 Reply
1 Like
Symptoms OCSP validation of client certificates for GlobalProtect is not working when using a Microsoft's Lightweight OCSP Profile Issue Confirm that validating the certificate outside of the firewall to the OCSP server is successful. Keep in mind that the firewall includes the nonce in the OCSP query Take a look at the following logs from mp-log sslmgr.log, for the following error message (or similar): Jul 30 15:46:59 sslmgr: ike mgr client certificate profile commit Jul 30 15:52:16 Error: pan_ocsp_parse_response(pan_crl.c:1262): [OCSP] The result of Certificate status query is unavailable for serial number[6128D58D000000000004] and uri[ http://labsrv1.stealthllama.local/ocsp ] Jul 30 15:52:16 Error: pan_ocsp_fetch_ocsp(pan_crl.c:1948): pan_ocsp_parse_response() failed There might also be error messages like the ones below: Jul 31 18:24:31 sslmgr_sysd_verify_cert(sslmgr_sysd.c:164): vsys id(1) profile name(StealthllamaClients) cert len (2034) obj len(2074) struct length(40) Jul 31 18:24:31 [OCSP] URL (null) serialno: 6128D58D000000000004 Jul 31 18:24:31 pan_ocsp_certchain_to_file(pan_crl.c:1066): root_ca_fname(Clr3Zk-uU9Jad2n) Jul 31 18:24:31 pan_ocsp_query_responder(pan_crl.c:1807): cetificate valid time information (Issuer: Not Before[Jul 29 15:51:18 2012 GMT]; Not After[Jul 29 16:01:16 2017 GMT]; Cert: Not Before[Jul 29 16:24:45 2012 GMT]; Not After[Jul 29 16:24:45 2013 GMT];) Jul 31 18:24:31 pan_ocsp_parse_response(pan_crl.c:1187): Responder Error: unauthorized (6) Jul 31 18:24:31 Error: pan_ocsp_parse_response(pan_crl.c:1262): [OCSP] The result of Certificate status query is unavailable for serial number[6128D58D000000000004] and uri[ http://labsrv1.stealthllama.local/ocsp ] Jul 31 18:24:31 Error: pan_ocsp_fetch_ocsp(pan_crl.c:1948): pan_ocsp_parse_response() failed Jul 31 18:24:31 sslmgr_check_status(sslmgr_main.c:671): [OCSP] Certificate status unavailable: depth:0 Resolution Enable that extension in the MicroSoft OCSP responder. Microsoft's Lightweight OCSP Profile does not support nonce extensions by default. However, it can be enabled by modifying the Revocation Configuration extensions. owner: dwhyte
View full article
npare ‎08-06-2012 12:37 PM
8,212 Views
1 Reply
Issue When importing a CA certificate generated by a Microsoft Certificate Authority to use as part of the SSL forward proxy decryption policy, the firewall returns this error: Import of certificate and private-key <name of cert> failed. Internal error. Failed to create xml node. The ms.log file reports more details on the error: Jul 24 16:04:53 client useridd reported op command was SUCCESSFUL Entity: line 4: parser error : xmlParseEntityRef: no name subject=/C=US/ST=California/L=SanJose/O=Palo Alto & Co/OU=Security ^ Jul 24 16:05:34 Error: pan_string_to_xml(pan_xml_utils.c:76): xmlParseMemory() failed Jul 24 16:05:34 Error: insert_cert_by_path_or_content(pan_ops_common.c:9483): In ternal error. Failed to create xml node. In the example above, the parsing error is caused by the ampersand character in the certificate's name Resolution Generate a new certificate without the "&" character to resolve the parsing error owner: acamacho
View full article
npare ‎07-25-2012 09:04 AM
9,765 Views
7 Replies
Ask Questions Get Answers Join the Live Community