Can we import PFX files through smartconsole

[Ryan_Ryan]

Hi,

this is just a general question and not relating to a current or specific issue. But the process of adding a CA signed SSL cert to the gateway is rather cumbersome for SSL VPN remote access gateway.

Current procedure is

- create the CA root certificate as a trusted CA on the gateway

- create the CA intermediate certificate as a trusted subordinate on the gateway

- generate a CSR through SmartConsole and select the intermediate certificate you created in step 2

- complete the certificate by installing the signed certifcated and hope and pray they have signed it using the same root cert you created the csr against else it will fail to bind and if so the only way around it to is generate a new csr and get it signed again.

Would seem a lot easier if the Smartconsole had an option to import a pfx, so we can create a csr and private key through any means we prefer (openssl or even cpopenssl) get it signed, bundle the private key, signed cert and chain together as pfx and upload it.

I know cpopenssl has some import options but I don't think it would allow us to import a cert and have it visible in the console for use.

[G_W_Albrecht]

Yes you can  8) See  sk69660: How to generate Server Certificate Signing Request (CSR) and import the new 3rd Party certi...:

Note: if you receive a .pfx file, rename the file extension from .pfx to .p12 and move to Stage 3 of this document

But this will not spare you to send the CSR file to a trusted certificate authority and request a Signed Certificate in PEM format.

[Ryan_Ryan]

Thanks for the reply, I did see that article, but interesting point on our gateway we do not even have Mobile Access gateway blade enabled. if you see the attachment in the original post that is where we apply the vpn certificate, (we are doing remote Access VPN in the IPsec config)

cheers

[G_W_Albrecht]

You did talk about SSL VPN - this is from MAB Blade, other is IPSec VPN...

[Tobias_Moritz]

Günther: I guess you know it already, but for all other people reading here: Depending on if you are using modern or legacy licences for your Remote Access VPN, you usually use Mobile Access or IPsec VPN blade. Even if your are only having IPsec VPN blade installed, you are still able to do SSL VPN in terms of Endpoint Security VPN in Visitor Mode, SSL Network Extender and so on. Of course you cannot use Mobile Access Portal without Mobile Access blade.

Ryan, in case you are running Remote Access VPN on a gateway which has only IPsec VPN blade installed, may I ask you which kind of Remote Access (Client) you are using against that gateway?

I'm asking because the environments I know which are operated this way (with Endpoint Security VPN as client), never needed to change the actual VPN certificate in the dialog in your screenshot but change the certificate the Multiportal Deamon is using for the SSL VPN endpoint, e.g. in using the Platform Portal dialog.

Reason: in trac.conf on EPS client, there are two fingerprints:

• <PARAM ccc_fingerprint="WHATEVER1"></PARAM>
  • This is the RfC#1751 encoded representation of the SHA-1 fingerprint of the Root-CA of the certificate added via SmartConsole -> Platform Portal.
  • Changing this certificate on gateway results in a popup on user side asking for trusting the new fingerprint
• <PARAM internal_ca_fingerprint="WHATEVER2"></PARAM>
  • This is the RfC#1751 encoded representation of the SHA-1 Fingerprints of the certificate added via SmartConsole -> IPSec-VPN.
  • Changing this certificate on gateway does NOT result in a popup on user side asking for trusting the new fingerprint

This is what I saw in my environments. There is another thread here on CheckMates where another customer is reporting that ccc_fingerprint is intermediate and not root in his case. He and I double checked it on our sides and we did not understand the difference yet, so please check on your side before trusting me or him 🙂

Leaving that aside, I agree to you that changing the VPN certificate in IPSec VPN dialog is really hard due to the process you described.

[G_W_Albrecht]

You are completely correct ! Anyway - in the MAB sk69660 it is also a complicated process and not much shorter...

[Ryan_Ryan]

Hi Tobias, thanks for the detailed reply.

I should have mentioned in the screenshot I have shown, I had already deleted my expired cert before replacing the new cert, I agree the default cert doesn't need to be renewed ever but that is the same place we have our real cert vpn.example.com aswell.

The clients use the old style SSL Extender, so they just browse to the gateway public ip, login and they get an SSL tunnel. 

It is possible the cert could be changed through multiportal rather than the gui interface, I had not thought of that might try that next time.

Your customer may have run into the same issue we did a year back, sometimes you need to generate the csr against the intermediate, and sometimes against the root depending on the signer (sk149253 - uses intermediate).

The other issue you can run into is, you cannot have two certs with the same DN, so when your cert comes up for expiry you need to do this in this order - delete your current cert, generate csr and install the signed cert. (assuming using the same root authority, else import their root/interm certs)