Certificate technology on

Junos Pulse Secure Access

How-to

Introduction: ........................................................................................................................................ 1
Creating a Certificate signing request (CSR): ................................................................................... 1
Import Intermediate CAs: …………………………………………………………………………………3
Using Trusted Client CA on Juno Pulse Secure Access device: .................................................... 5
Import Trusted Client CA Certificates ............................................................................................... 5
Configuring Options for Trusted Client CA Certificates: ................................................................. 6
Configure Certificate Server …………………………………….…………………………………………………………… 8
Configure Certificate Restrictions ……………………………………………………………………………………...…. 9
Using Trusted Server CAs................................................................................................................. 10
Uploading Trusted Server CA Certificates ………………………………………..…………………………………. 11
Using Code-signing Certificates....................................................................................................... 12
Importing a Code-Signing CA Certificate ……………………………..……………………………………………….12
Certificates Troubleshooting tips: ................................................................................................... 14

© Juniper Networks, Inc.

 Certificate technology on IVE how-to document

Introduction:

A device certificate helps to secure network traffic to and from a Junos Pulse Secure Access using a
combination of X.509 certificates and symmetric key encryption.

When you initialize a Junos 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 Junos 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. W hen 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.

© Juniper Networks, Inc. 1

 Certificate technology on IVE how-to document

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 email message to the CA.
• Paste the text into an email message to the CA
• Paste the text into a W eb 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

© Juniper Networks, Inc. 2

 Certificate technology on IVE how-to document

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.

3. Click Import CA Certificate

© Juniper Networks, Inc. 3

 Certificate technology on IVE how-to document

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

© Juniper Networks, Inc. 4

 Certificate technology on IVE how-to document

Using Trusted Client CA on Juno Pulse Secure Access device:

Junos 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 Junos Pulse Secure Access device for client
authentication. After added to the Trust Client CA list, Junos 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, Junos Pulse Secure Access device validates the certificate is a
valid (not expired) and signed by a certificate authority in the Trusted Client CA list. Junos 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.

© Juniper Networks, Inc. 5

 Certificate technology on IVE how-to document

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.

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.

© Juniper Networks, Inc. 6

 Certificate technology on IVE how-to document

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

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)

© Juniper Networks, Inc. 7

 Certificate technology on IVE how-to document

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.

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.

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.

© Juniper Networks, Inc. 8

 Certificate technology on IVE how-to document

Configure Certificate Restrictions:

A client certificate can be used to restrict access to the Junos 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 Junos 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
2. From the Rule Based on drop down, select Certificate
3. Click Update

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.

© Juniper Networks, Inc. 9

 Certificate technology on IVE how-to 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..

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 Junos Pulse Secure Access software versions. Trusted Server CA are utilized by the Junos 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
• Junos Pulse Secure Access device is making a secure connection (SSL) to a backend resource that is
issued from a Private CA

© Juniper Networks, Inc. 10

 Certificate technology on IVE how-to document

Uploading Trusted Server CA Certificates

Junos 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

2. Click Import Trusted Server CA

3. Browse to the certificate file
4. Click Import Certificate

Note: When import a certificate hierarchy, certificates should be imported starting from the top down.

© Juniper Networks, Inc. 11

 Certificate technology on IVE how-to document

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
Junos 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 Juniper components (Host Checker, Network Connect, etc.) via Java

When the Junos 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 http://www.verisign.com/products-services/security-services/code-

signing/index.html.

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 email with installation
instructions. Once the installation is complete, import the code signing certificate to the Junos 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.
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 Junos 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 Junos 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.

© Juniper Networks, Inc. 12

 Certificate technology on IVE how-to document

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

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

© Juniper Networks, Inc. 13

 Certificate technology on IVE how-to document

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 JTAC case and provide a system snapshot include debug logs
and system configuration.
b. If no message appears, no client certificate was provided to the Junos 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

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 JTAC to further determine the cause of the above issue.

© Juniper Networks, Inc. 14