Certificate technology on Pulse Secure Access

Transcription

1 Certificate technology on Pulse Secure Access How-to Guide Published Date July 2015

2 Contents Introduction: 3 Creating a Certificate signing request (CSR): 3 Import Intermediate CAs: 5 Using Trusted Client CA on Pulse Secure Access device: 7 Import Trusted Client CA Certificates: 7 Configuring Options for Trusted Client CA Certificates: 8 Configure Certificate Server: 11 Configure Certificate Restrictions: 12 Using Trusted Server CAs 14 Uploading Trusted Server CA Certificates 14 Using Code-signing Certificates 15 Importing a Code-Signing CA Certificate 15 Certificates Troubleshooting tips: 17 2

3 Introduction: A device certificate helps to secure network traffic to and from a Pulse Secure Access using a combination of X.509 certificates and symmetric key encryption. When you initialize a Pulse Secure Access device, a temporary self-signed certificate will be created locally that enables users to immediately begin using the device. Please note, encryption with the self-signed certificate is perfectly safe, but users will be prompted with a security alert each time they sign in to the device because the certificate is not issued by a trusted certificate authority (CA). For production purposes, we recommend to obtain a digital certificate from a public certificate authority (like VeriSign, Thawte, etc.). Signed device certificate can be added to Pulse Secure Access device by creating a certificate signing request (CSR) through the administrator web interface, then send the request to a CA for processing. When a CSR is created through the admin web interface, a private key is created locally that corresponds to the CSR. If the CSR is deleted, the private key will be deleted as well, and prohibit installation of the signed certificate that matches the CSR. Creating a Certificate signing request (CSR): 1. In the administrator web interface, navigate to System > Configuration > Certificates > Device Certificates. 2. Click New CSR. 3. Enter the required information (CN and Organization are required fields) and click Create CSR. The Certificate Signing Request page appears with encoded text. 3

4 4. Submitting the CSR to a Certificate Authority (CA) for signing. You need to copy the encoded text below -----BEGIN CERTIFICATE REQUEST----- (Certificate hash) -----END CERTIFICATE REQUEST----- Ensure to copy the begin and end lines and submit it to your certificate authority in one of the following ways: Save the text as a.cert file and attach it to an message to the CA. Paste the text into an message to the CA Paste the text into aweb form provided by the CA Note: When submitting a certificate signing request (CSR) to a CA authority, you may be asked to specify the type of Web server. Select apache_modssl (if more than one option with apache_modssl is available, choose any). Also, if prompted for the certificate format to download, select X.509 or Base- 64 format. 5. When you receive the signed certificate from the CA, perform the following steps below: a. In the administrator Console, navigate to System > Configuration > Certificates > Device Certificates b. Click Pending Certificate Signing Request link. c. Browse to the certificate file you received from the CA (cert.cer) and click Import 4

5 Import Intermediate CAs: If the certificate is issued from an intermediate certificate, you will need to import the intermediate CAs under Intermediate Devices CAs. Within a certificate hierarchy, one or more intermediate certificates may be issued from a single root certificate. The root certificate is issued by a root certificate authority (CA) and is self-signed. Each intermediate certificates is issued by the certificate above it in the chain. 1. In the administrator web interface, navigate to System > Configuration > Certificates > Device Certificates. 2. Click Intermediate Device CAs. 5

6 3. Click Import CA Certificate 4. Click Choose File 5. Browse to the Intermediate CA file 6. Click Import Certificate Note: Ensure certificates are added starting from the top-down (Root > Intermediate). Check for certificate validity and replace any expired certificates 6

7 Using Trusted Client CA on Pulse Secure Access device: Pulse Secure Access device supports X.509 CA certificates in DER and PEM encoded formats. A trusted client CA is a certificate authority (CA) trusted by the Pulse Secure Access device for client authentication. After added to the Trust Client CA list, Pulse Secure Access gateway will trust any certificate issued by the CA. To use client CA certificates, you must install and enable the proper root CA certificates. Additionally, you must install a client certificate in the web browsers of your end-users machine or use MMC Certificates snap-in for computer accounts (machine certificate). When validating a client-side CA certificate, Pulse Secure Access device validates the certificate is a valid (not expired) and signed by a certificate authority in the Trusted Client CA list. Pulse Secure Access device will validate all certificates in hierarchy until it reaches the root CA, checking the validity of each issuer as it goes up the CA chain order. Import Trusted Client CA Certificates: 1. Navigate to Configuration > Certificates > Trusted client CAs 2. Click Import CA Certificate 3. Click Choose File. Select top-level root certificate 4. Click Import Certificate Note: Perform step 3 and 4 for each intermediate certificate in the hierarchy. The above example was imported in the following order, IB/A > AC access > AC radio\e4\log > AC netaccess logic. 7

8 Configuring Options for Trusted Client CA Certificates: CRL (Certificate Revocation List) - A certificate revocation list (CRL) is a mechanism for cancelling a client-side certificate. As the name implies, a CRL is a list of revoked certificates published by a CA or delegated CRL issuer. The system supports base CRLs, which include all of the company s revoked certificates in a single, unified list. 8

9 To configure CRL client certificate status checking, perform the following steps: 1. From the Trusted Client CA list, click on the CA certificate which signs the end user certificates. 2. Under client certificate status checking, select the radio button Use CRLs (Certificate Revocation Lists). 3. Click Save Changes 4. Under CRL Settings, select CRL Checking Options. 5. From the Use drop-down, select CDP(s) specified in client certificates 6. Click Save Changes In rare instances, the CDP may not be given in the client certificates. In this scenario, change from CDP(s) specified in client certificates to Manually configured CDP. For CDP information, please reach out to your certificate authority administrator to confirm the CDP URL and LDAP credentials (if LDAP is utilized) Note: The above example is only to perform CRL checking for client certificates. In rare situation, if CRL checking is required for each CA in the hierarchy, you will need to configure CRL check for each CA and select CDP(s) specified in the Trusted Client CA. OCSP (Online Certificate Status Protocol) - The Online Certification Status Protocol (OCSP) is a service that enables you to verify client certificates. When OCSP is enabled, the system becomes a client of an OCSP responder and forwards validation requests for users based on client certificate. The OCSP responder maintains a store of CA-published certificate revocation lists (CRLs) and maintains an up-to-date list of valid and invalid certificates. After the OCSP responder receives a validation request, it validates the status of the certificate using its own authentication database, or it calls upon the OCSP responder that originally issued the certificate to validate the request. After formulating a response, the OCSP responder returns the signed response, and the original certificate is either approved or rejected. Comparison to CRLs vs OCSP: Using OCSP, clients do not need to parse CRLs themselves. OCSP provide real-time response while CRL data are periodically updated under a given interval determined by the CA To configure OCSP client certificate status checking, perform the following steps: 1. From the Trusted Client CA list, click on the CA certificate which signs the end user certificates. 2. Under client certificate status checking, select the radio Use OCSP 3. Click Save Changes 4. Under OCSP Settings, click OCSP Options 9

10 5. From the Use drop-down, click Responder(s) specified in the client certificates 6. Click Save Changes Additional configuration may be required if the OCSP response does not included the OCSP responder certificate or the response is not signed by a CA certificate. For more details, refer to Configuring Options for Trusted Client CA Certificates (Figure 7 and Figure 8) Additional Recommendations: By default, Trusted for Client Authentication and Participate in Client Certificate Negotiation are enabled after importing any CA certificate. The recommendation is to disable Participate in Client Certificate Negotiation for all CA certificates in the hierarchy except the CA certificate which signs all end user certificates. This will ensure end users will only be able to select certificates signed by the signing CA certificate instead of all potential certificates signed by the top level root and its intermediate CAs. 10

11 Configure Certificate Server: The certificate server is a local server that allows user authentication based on the digital certificate presented by user without any other user credentials. Additional, the system does extract values from the distinguished name (DN) field of the end user certificate and can be used for role mapping rules, authentication policies and role restrictions. To configure a certificate server, perform the following steps: 1. From the administrator console, navigate to Authentication > Auth. Servers. 2. From the drop-down, select Certificate Server > New Server. 3. In the Name field, enter a friendly name for the certificate server 4. In the User Name template, enter the variable where the user name is contained. By default, <certdn.cn> will be the using the common name field in the end user certificate. 11

12 5. Click Save Changes Note: To add role mapping rules based on certificate expressions, refer to Specifying Role Mapping Rules for an Authentication Realm documentation. Configure Certificate Restrictions: A client certificate can be used to restrict access to the Pulse Secure Access (Realm restriction) and resource access (Role restriction). To implement certificate restrictions at the realm level, navigate to: Administrators > Admin Realms > SelectRealm> Authentication Policy > Certificate Users > User Realms > SelectRealm > Authentication Policy > Certificate Select Only allow users with a client-side certificate signed by a Trusted Client CAs to sign in. If the machine does not possess a valid client certificate, the end user will be able to access the sign-in page, but the Pulse Secure Access device will not submit the user s credentials to the authentication server. To role map using certificate attributes, select Allow all users and remember certificate information while user is signed in. 1. Navigate to Users > User Realms > SelectRealm > Role Mapping > New Rule From the Rule Based on drop down, select Certificate Click Update 12

13 4. In the Attribute field, enter the corresponding certificate attribute used to map the role For a list of possible certificate attributes, refer to System Variables and Examples document. To implement certificate restrictions at the role level, navigate to: Administrators > Admin Roles > SelectRole > General > Restrictions > Certificate Users > User Roles > SelectRole > General > Restrictions > Certificate Select Only allow users with a client-side certificate signed by a Certificate Authority.. 13

14 If the machine does not possess a valid client certificate, the end user will not be mapped the user to that role. Using Trusted Server CAs By default, all trusted root CAs from Internet Explorer 7.0 and Windows XP Service Pack 2 are preinstalled on all Pulse Secure Access software versions. Trusted Server CA are utilized by the Pulse Secure Access web server to trust incoming SSL connections from external end users and backend resources. Normally, Trusted Server CA list does not need to be updated unless one of the following conditions are met: Public / Private CA has provided an updated root and intermediate certificates for your device certificate Device certificate has been issued from a new Private CA Pulse Secure Access device is making a secure connection (SSL) to a backend resource that is issued from a Private CA Uploading Trusted Server CA Certificates Pulse Secure Access support X.509 CA certificates in PEM (Base 64) or DER (binary) encode formats. To upload CA certificates: 1. Select System > Configuration > Certificates > Trusted Server CAs 14

15 1. Click Import Trusted Server CA 2. Browse to the certificate file 3. Click Import Certificate Note: When import a certificate hierarchy, certificates should be imported starting from the top down. Using Code-signing Certificates After the recent changes with Java 7 Update 51, all java applets are required to be signed by a trusted certificate authority. Due to the changes, a code-signing certificate is recommended to be installed on the Pulse Secure Access device if one of the following conditions are met: End users are accessing signed java applets through (web) core access or rewrite engine End users are downloading Pulse Secure components (Host Checker, Network Connect, etc.) via Java When the Pulse Secure Access rewrites a signed Java applet, it re-signs the applet with a self-signed certificate by default. This certificate will not be trusted and will cause Java to block the java applet. The system supports the following code-signing certificates: Microsoft Authenticode Certificate JavaSoft Certificate Both certificates can be purchased at Importing a Code-Signing CA Certificate To import a code-signing certificate: 1. Purchase a VeriSign/Symantec Java or Microsoft Authenticode code signing certificate 2. The approval process may take several days and you will be sent an with installation instructions. Once the installation is complete, import the code signing certificate to the Pulse Secure Access gateway device. A. Microsoft Authenticode Certificate 1. Download OpenSSL. 2. Export the code signing certificate from Windows. For vendor instructions, click here. This will create a <filename>.pfx. 15

16 3. Run the following openssl command to export the private key: openssl pkcs12 -in <filename>.pfx -nocerts -nodes -out private.key 4. Run the following openssl command to export the public key: openssl pkcs12 -in <filename>.pfx -nokeys -out public.cer 5. Access the Pulse Secure Access administrator page 6. Navigate to System > Configuration > Certificates > Code-Signing Certificates > Import Certificates 7. For Certificate File, browse to the location of the public.cer 8. For Private Key File, browse to the location of the private.key 9. For Password Key, enter the private key password 10. Click Import. B. Javasoft Certificate 1. Access the Pulse Secure Access administrator page. 2. Navigate to System > Configuration > Certificates > Code-Signing Certificates > Import Certificates 3. For Keystore File, browse to the location of the Java keystore 4. For Password key, enter the Java keystore password. 5. Click Import. 3. Navigate to Users > Resource Policies > Java > Code-Signing (If Java does not appear, click Customize in the upper right hand corner and select the checkbox for Java and Code-Signing) 4. Click New Policy 16

17 5. In the Name field, enter a friendly name for the policy 6. In the Resource field, enter the IP addresses and/or fully qualified domain names to apply the policy to for resigning applets with the installed code-signing certificate 7. Under Roles, select Policy applies to SELECTED roles and select the corresponding roles to apply the policy to 8. For Action, select Resign applets using Code-Signing Certificate 9. Click Save Changes Certificates Troubleshooting tips: Certification Authentication issues 1. Certificate authentication is failing with the message Missing or invalid certificates, check the user access logs and confirm if the same error appears. a. If the same message appears, enable debug logging at level 10 with the following event codes Certificate,CRL,OCSP,SSL. Open a GSC case and provide a system snapshot include debug logs and system configuration. 17

18 b. If no message appears, no client certificate was provided to the Pulse Secure Access device. Ensure the following conditions are met: i. Certificate is not expired ii. Certificate has the key usage of Client Authentication iii. Certificate is signed by a certificate authority that exists in the Trusted Client CAs list 2. No certificate prompt appears when multiple client certificate are installed, confirm if Participate in Client Certificate Negotiation is enabled on the signing CA. 3. Multiple certificates appear from different signing CA, but from the same root, disable Participate in Client Certificate Negotiation from all CAs in the hierarchy except the correct signing CA. Code-Signing issues 1. Uploaded code-signing certificate is not re-signing java applets a. Java code-signing policy (Resource Policies > Java > Code-Signing) is configured b. Clear Java cache from the Java c. Disable Enable Java instrumentation caching (Maintenance > System > Options) and retry. Note: Ensure to enable this option after the issue is resolved or once testing has completed. Trusted Server CA issues 1. Untrusted messages are appearing after importing a new device certificate a. Import new intermediate CA under Configuration > Certificates > Device Certificates > Intermediate CAs (above Import Certificate & Key button) b. Import new root CA under Trusted Server CA 2. Untrusted messages are appearing when accessing a backend resource a. Import the corresponding root CA for the certificate installed on the backend resource under Trusted Server CA b. Select Allow browsing untrusted SSL websites under the corresponding user role and disable Warn users about the certificate problems 18

19 Troubleshooting approach: 1. Gather system logs (event, user access and admin access) 2. Enable debug logging at level 10 with the following event codes Certificate,CRL,OCSP,SSL and replicate the issue 3. Take system snapshot include debug log and system configuration 4. Provide a copy of the client certificate public key The above files will help GSC to further determine the cause of the above issue. 19