This guide shows you how to generate a CSR (Certificate Signing Request) on Ivanti Connect Secure, the SSL VPN appliance sold for years as Pulse Secure. You create the request in the admin console under System > Configuration > Certificates > Device Certificates, fill in your organization details, and copy the encoded request into your certificate order. The appliance creates the matching private key at the same time and keeps it on the device, so the signed certificate has to come back to the same appliance, into the same pending request.
A note on the name, because both are still in use. The product started life as Juniper Networks’ Junos Pulse. In 2014 Siris Capital bought that business from Juniper and formed Pulse Secure, and on 1 December 2020 Ivanti acquired Pulse Secure and renamed the range: Pulse Connect Secure became Ivanti Connect Secure, Pulse Policy Secure became Ivanti Policy Secure, and the desktop app most people called Pulse Secure is now the Ivanti Secure Access Client. Only the branding changed for this task. The menu path, the button names, and the form below are the ones Ivanti documents for the current 25.1 releases, and they are the same on the older 22.x and 9.1 builds that still show Pulse branding.
Generate the CSR on Ivanti Connect Secure (Pulse Secure)
If you have already generated your CSR and received the signed files from the CA, skip this section and go straight to how to install an SSL certificate on Ivanti Connect Secure. Otherwise, work through the four steps below. Before you start, decide the exact host name your users type to reach the VPN, because that is the name the certificate has to carry.
Step 1: Open the Device Certificates page
- Sign in to the admin console of your Ivanti Connect Secure appliance.
- Select System > Configuration > Certificates > Device Certificates.
- The certificates already on the appliance are listed at the top of the page under Certificate issued to. Scroll past that list to the New CSR button, which sits just above the Certificate Signing Requests table, and click it. The request form opens.
Step 2: Fill in the requestor information
Everything you type here goes into the request, and most of it into the issued certificate. Spell values out in full and do not abbreviate.
- Common Name: the fully qualified domain name the certificate has to secure, for example vpn.yourcompany.com. This must be the name users actually type in the browser or in the Ivanti Secure Access Client, not the appliance’s internal host name. For a wildcard certificate, put an asterisk in front of the domain instead, for example *.yourcompany.com.
- Organization Name: the full legal name of your company as registered, for example Your Company LLC. A Domain Validated certificate ignores it, but Organization Validated and Extended Validation certificates are checked against company records, so a nickname or trading name will hold up your order.
- Org. Unit Name: leave it blank. Since 1 September 2022 the CA/Browser Forum Baseline Requirements have barred public CAs from putting the Organizational Unit into issued certificates, so anything you type here is discarded.
- Locality: the city where your business is registered, written out in full, for example San Jose. This is your registered address, not where the appliance is racked.
- State (fully spelled out): the state or province of that registered address, spelled out, for example California and not CA.
- Country (2 letter code): the two-letter ISO country code, for example US.
- Email Address: a contact address. Public CAs run validation through the contact details on your order rather than through this field, so it does not decide who receives the approval emails.
Watch out for apostrophes. Ivanti documents that an apostrophe inside any of these values has to be escaped with a backslash, so a company registered as Children’s Trust is entered as Children\’s Trust. Miss that and the request either fails to generate or comes back with the name mangled.
Step 3: Choose the key type and length
Below the requestor fields, the form asks how the key pair should be built. Three settings appear here, and the first two decide whether your CA will accept the request, so do not skip past them.
- Key Type: leave it on RSA unless you have a specific reason to do otherwise. Selecting ECC brings up an ECC Curve menu: Ivanti’s own worked example creates a P-256 request, and its Suite B guidance covers P-256, P-384 and P-521. Two conditions come with that choice: Ivanti documents ECC certificates as supported only on the ISA Series gateways and virtual appliance platforms, and once an ECC certificate is bound to a network port, only clients that support ECC cipher suites can connect on that port. RSA avoids both questions.
- Key Length: choose 2048 at a minimum, the smallest RSA key public CAs will sign. The menu still lists 1024, so make sure you change it. 3072 or 4096 are also fine if your policy calls for a larger key. Current Ivanti Connect Secure releases document support for device certificate keys up to 8192 bits, but older releases documented a 3072-bit ceiling, so check what your build offers before you plan around a large key.
- Random Data: type a long run of random characters into this box. The appliance mixes what you type into its random number generator when it creates the key. There is nothing to remember here and nothing to write down.
One version note worth knowing. From release 25.1.0.0 onward, Ivanti Connect Secure no longer accepts SHA-1 in digital signatures, and an appliance holding only SHA-1 signed device certificates fails to launch its user interface. Public CAs stopped issuing SHA-1 certificates at the beginning of 2016, so a certificate ordered today from a public CA is unaffected. It matters if you are requesting from an internal or legacy CA: make sure it signs with SHA-256 or better.
Step 4: Create the request
Read every field back before you commit, then click Create CSR. The appliance generates the request and, at the same moment, the private key that belongs to it. The key stays on the device and is never shown to you or sent to the CA.
The next screen confirms the request was created. Scroll down and you will see the encoded request itself, ready to copy or save to a file.
Copy the CSR and send it to your CA
The block on screen looks like this:
-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
... (many lines of base64) ...
-----END CERTIFICATE REQUEST-----Select the whole thing, including the —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—– lines. Each marker carries five hyphens on either side. Note the word REQUEST: a certificate signing request is not delimited by BEGIN CERTIFICATE, and pasting the shorter marker is a common reason an order form rejects the request. Paste the block into a plain text editor such as Notepad or TextEdit, then into the CSR box on your order form. Do not use a word processor, which can substitute characters and break the encoding.
Click Back to Device Certificates when you are done. Your request now appears under Certificate Signing Requests as a Pending CSR link, and you can reopen it at any time to copy the text again.
Two things to avoid while you wait:
- Do not delete the pending CSR. Ivanti is explicit about the consequence: deleting the request deletes the private key with it, and you will not be able to install the certificate issued from it. If that happens, the only route is a new CSR and a reissue.
- Do not send more than one CSR to a CA at a time. Ivanti warns that doing so can result in duplicate charges.
If the order form asks which web server the certificate is for, choose Apache, or any Apache option if several are listed. If it asks for a certificate format, take the standard one. Both are Ivanti’s own recommendations for this appliance.
Check the CSR before you submit it
A typo in the Common Name means the CA issues a certificate your users cannot use, and a reissue costs you another validation round. Paste the request into our CSR Decoder and read it back: the Common Name should be the exact host name users type, and the organization details should match your registration. If anything is wrong, create a new CSR on the appliance. Never edit the encoded text, because the request is signed by its own private key and any change invalidates it.
If you have OpenSSL on a workstation, save the request to a file and run the same check locally:
openssl req -noout -text -verify -in vpn.csrIt prints the subject, the key size and a line confirming the request verifies against its own key.
When the built-in form is not enough
The New CSR form asks for a single Common Name and has no field for additional host names, so it cannot build a request for a multi-domain (SAN) certificate. If one certificate has to cover several distinct names, for example vpn.yourcompany.com and portal.yourcompany.com, build the request outside the appliance and import the certificate together with its key afterwards. A wildcard certificate does not need this: enter the wildcard as the Common Name and the built-in form handles it.
Our CSR Generator builds a SAN request from a single form. If you would rather use OpenSSL on any machine, this produces the request and the key together:
openssl req -new -newkey rsa:2048 -nodes \
-keyout vpn.key \
-out vpn.csr \
-subj "/CN=vpn.yourcompany.com/O=Your Company LLC/L=San Jose/ST=California/C=US" \
-addext "subjectAltName=DNS:vpn.yourcompany.com,DNS:portal.yourcompany.com"Repeat the Common Name as the first entry in the SAN list, as shown. Clients match the host name against the SAN entries and ignore the Common Name, so a name that appears only in the CN is not covered. Keep vpn.key somewhere safe: with a request created this way, the appliance is not holding the key, so you supply it yourself at import time through Import Certificate & Key rather than through a pending CSR.
After the CA issues your certificate
When validation completes, the CA emails you the signed certificate and its intermediate (CA) chain, usually in a ZIP archive. Extract it, then go back to System > Configuration > Certificates > Device Certificates, click the Pending CSR link that matches, and under Import signed certificate browse to the file and click Import. Importing onto the pending request is what pairs the certificate with the key the appliance has been holding since Step 4.
The appliance takes X.509 certificates in DER or PEM encoding (.cer, .crt, .der and .pem files) as well as PKCS#12 (.pfx and .p12). Importing the certificate is not the last step: you still have to add the intermediate certificates and bind the new certificate to your ports before anything changes for users. Our guide on how to install an SSL certificate on Pulse Secure SSL VPN covers both.
If you are replacing a certificate that is about to expire, you have a choice. Creating a new CSR as described above is the option Ivanti calls the more secure one, because the CA issues a new certificate against a new key and the old key is retired. The alternative keeps the existing key, and Ivanti calls it the less secure one: order the renewal from your CA by resubmitting your original CSR, or by confirming the CA still has it on record, then open the certificate in the list, click Renew Certificate, browse to the renewed file and click Import. That saves you building a new request, at the cost of carrying the same key forward.
Frequently Asked Questions
In the admin console, select System > Configuration > Certificates > Device Certificates and click New CSR. Fill in the requestor information and the key settings, then click Create CSR. The encoded request appears on the next screen, and the request is listed as Pending until you import the signed certificate.
Yes. Ivanti acquired Pulse Secure on 1 December 2020 and renamed the products: Pulse Connect Secure became Ivanti Connect Secure, Pulse Policy Secure became Ivanti Policy Secure, and the Pulse Secure desktop client became the Ivanti Secure Access Client. The certificate workflow did not change, so these steps apply whether your appliance still carries Pulse branding or the newer Ivanti branding.
No. The appliance creates the key locally when you click Create CSR and keeps it out of sight. Only the request is displayed, and only the request goes to the CA. That is why the signed certificate has to be imported back onto the same appliance, into the same pending request, and why you should never delete a pending CSR while you are waiting: deleting it deletes the key too, and the certificate issued from it becomes unusable.
RSA with a Key Length of 2048 suits almost every deployment, and 2048 bits is the smallest key public CAs will sign. Pick 3072 or 4096 if your security policy asks for a larger key. Choose ECC only deliberately: Ivanti documents ECC certificates as supported only on the ISA Series gateways and virtual appliance platforms, and only clients that support ECC cipher suites can connect on a port serving an ECC certificate.
Not through the built-in form, which takes one Common Name and offers no field for extra names. A wildcard works, so enter *.yourcompany.com as the Common Name if all your host names sit under one domain. For genuinely different names, create the request with our CSR Generator or with OpenSSL, keep the private key yourself, and load both through Import Certificate & Key instead of through a pending CSR.
No. The request is signed by its own private key, so editing a single character makes it invalid. Create a new CSR on the appliance with the correct values and submit that one. You can delete the faulty pending request once the replacement is in place, as long as no certificate has been issued against it.
Because those are two different objects. —–BEGIN CERTIFICATE REQUEST—– marks a CSR, the block you send to the CA. —–BEGIN CERTIFICATE—– marks an issued certificate, the block the CA sends back. Copy the request with its own markers intact, all five hyphens on each side, and nothing before or after them.
Save 10% on SSL Certificates when ordering from SSL Dragon today!
Fast issuance, strong encryption, 99.99% browser trust, dedicated support, and 25-day money-back guarantee. Coupon code: SAVE10
