Showing posts with label VPN. Show all posts
Showing posts with label VPN. Show all posts

Wednesday, February 22, 2017

Renew Cisco IOS IPSec VPN Certificates from Symantec

I am not sure if there is other better way to do it. There is no good documentation from Cisco or somewhere else regarding how you should do on renewing your ssl certificates once it is expired. Every a couple of years, I have to face this problem,  renewing all routers ssl certificates. As far as I know, you can not renew current existing certificates, you will have to created a new trustpoint , generate new CSR and import a renewed certificate. Actually you can use same trustpoint configuration configured before as long as you are using different trustpoint name.

I recorded those steps again which I did a couple of years ago in following posts:

Thursday, August 4, 2016

Cisco Configuration Professional (CCP) Configure IOS SSL VPN (AnyConnect SSL VPN)

Basic Cisco Configuration Professional (CCP) configuration has been posted before at following link:
This Post will demonstrate how to use CCP to configure SSL VPN on an IOS Router.

1. Confirm SSL-VPN License Installed

You can review another post regarding how to add Cisco license into a router.

Wednesday, April 27, 2016

Troubleshooting Cisco IPSec Site to Site VPN - "IPSec policy invalidated proposal with error 32"

There was vpn set up recently using Cisco Router to connect Check Point firewall. It seems quite simple task but "IPSec policy invalidated proposal with error 32" made me go through all troubleshooting steps which shows below.

Other examples to troubleshoot IPSec VPN issue:



Topology is quite simple:

Monday, February 22, 2016

Cisco ASA Remote Access VPN Configuration 2 - AnyConnect VPN

Basic Cisco AnyConnect full-tunnel SSL VPN uses user authentication by username and password, provides IP address assignment to the client, and uses a basic access control policy. The client also authenticates the ASA with identity certificate-based authentication. Deployment tasks in this post are as follows:
  • Configure the basic ASA SSL VPN gateway features.
  • Configure local user authentication.
  • Configure IPv4/IPv6 address assignment.
  • Configure basic access control.
  • Install the Cisco AnyConnect Secure Mobility Client.
Initially, AnyConnect was an SSL-only VPN client. Starting with Version 3.0, AnyConnect became a modular client with additional features (including IPsec IKEv2 VPN terminations on Cisco ASA), but it requires a minimum of ASA 8.4(1) and ASDM 6.4(1).

Related posts in this blog:
1. Topology

In this post, Cisco Adaptive Security Appliance Software Version 9.1(2) and Device Manager Version 7.1(3) have been used as an example.


DMZ (Security Level 50) interface will be used to simulate external connection to Internet.
INTERNAL (Security Level 100) interface is connecting to local network.

Friday, February 19, 2016

Cisco ASA Remote Access VPN Configuration 1 - Clientless SSL VPN

Remote access VPNs let single users connect to a central site through a secure connection over a TCP/IP network such as the Internet. Unlike other common VPN client solutions, the Clientless SSL VPN does not require that a client download and install a VPN client, all communications to the central location (where the ASA is located) are done via Secure Socket Layer (SSL) or its successor, Transport Layer Security (TLS).


This post describes how to build a remote access VPN connection using Clientless SSL VPN feature.
Related posts in this blog:

1. Topology



Monday, January 11, 2016

Cisco IKEv1 Site-to-Site IPSec Configuration on IOS Routers (1) - High Availability IPSec

IPsec is a framework of open standards that provides data confidentiality, data integrity, and data authentication among participating peers. It provides these security services at the IP layer; it uses Internetwork Key Exchange (IKE) to handle negotiation of protocols and algorithms based on local policy, and to generate the encryption and authentication keys to be used by IPsec. You can use IPsec to protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

“IKE,” which stands for “Internet Key Exchange,” is a protocol that belongs to the IPsec protocols suite. Its responsibility is in setting up security associations that allow two parties to send data securely. IKE was introduced in 1998 and was later superseded by version 2 roughly 7 years later.

This post summarizes typical Cisco IOS IPSec VPN IKEv1 set up. It includes standalone or High Availability implementation. The next post will includes how to use different CA to authenticate IKE.  It focus on IKEv1 (Internet Key Exchange version 1). Later IKEv2 will be summarized in this blog.

Typical Topology:
R1: G0/0 - 19.26.116.141 (It is VIP in high availability deployment)
R2: G0/0 - 19.26.116.137

R1: G0/1 - Internal Interface for network 192.168.20.x/24
R2: G0/1 - Internal Interface for network 172.21.91.x/24

Saturday, January 9, 2016

Using Symantec SSL PKI to Authenticate Cisco IOS IPSec VPN - HA Deployment

Digital certificates as an authentication method for IPSec VPNs is becoming increasingly popular for both remote access and site-to-site deployments. The use of digital certificates requires some form of PKI infrastructure such as a CA server. In this post, Symantec public CA will be used as an example to authenticate certificates used between two IPSec VPN gateways. There are some other posts in this blog relating to this topics, please check them using following list:

This post is mainly used to document the steps how to built a Third Party Based Certificates IPSec VPN, including how to submit gateway's CSR to Symantec and get your certs signed by Symantec CA and how to install those signed certs on your gateways. The first 8 steps are same for both for standalone deployment and high availability implementation. Only difference will be at step 9 for only used in high availability configuration.

Wednesday, January 6, 2016

Cisco IKEv1 Site-to-Site IPSec Configuration on IOS Routers (2) - Using Two Different CA Certificates

Pre-shared keys and digital certificates are two primary authentication methods in IKE that can be used in the context of IPSec VPN deployments.

Digital certificates provide a means to digitally authenticate devices and individual users. An individual that wishes to send encrypted data obtains a digital certificate from a Certificate Authority (CA). The CA issues an encrypted digital certificate containing the applicant's public key and a variety of other identification information. The CA makes its own public key readily available. The recipient of the encrypted message uses the CA's public key to decode the digital certificate attached to the message, verifies it as issued by the CA, and then obtains the sender's public key and identification information held within the certificate. With this information, the recipient can send an encrypted reply. Public key infrastructure (PKI) is the enabler for managing digital certificates for IPSec VPN deployment. The most widely used format for digital certificates is X.509, which is supported by Cisco IOS.

Saturday, August 15, 2015

Policy Based IPSec VPN Configuration Between SRX Firewalls

Juniper SRX support both Route-based and Policy-based VPN, which can be used in different scenarios based on your environments and requirements. 


Difference between them (KB15745)

With policy-based VPN tunnels, a tunnel is treated as an object that together with source, destination, application, and action, comprises a tunnel policy that permits VPN traffic. In a policy-based VPN configuration, a tunnel policy specifically references a VPN tunnel by name.

With route-based VPNs, a policy does not specifically reference a VPN tunnel. Instead, the policy references a destination address. When the security device does a route lookup to find the interface through which it must send traffic to reach that address, it finds a route via a secure tunnel (ST) interface, which is bound to a specific VPN tunnel.

Thus, with a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy. With a route-based VPN tunnel, you can consider a tunnel as a means for delivering traffic, and the policy as a method for either permitting or denying the delivery of that traffic.

Scenarios to use them:  

The following are reasons why you implement route-based VPN:
  • Source or destination NAT (NAT-src or NAT-dst) needs to occur as traffic travels through the VPN.
  • There are overlapping subnets or IP addresses between the two LANs.
  • Hub-and-spoke VPN topology is used in the network.
  • Primary and backup VPN are required.
  • A dynamic routing protocol (for example, OSPF, RIP, or BGP) is running across the VPN.
  • Multiple subnets or networks at the remote site across the VPN need to be accessed.
The following are reasons why you implement policy-based VPN:
  • The remote VPN device is a non-Juniper device.
  • Only one subnet or one network at the remote site across the VPN needs to be accessed.

Route-Based VPN Configuration Procedures

My previous posts (Using PKI Build Route-Based IPSec VPN between Juniper SRX) have shown the configuration Route-Based VPN between two SRX firewalls. This Post will present the procedures how to use policy-based VPN.

Topology:


Two Juniper SRX Firewalls.
FW1:
External Interface Reth0.0 = 192.168.9.18
Internal Interface Reth1.0 = 10.94.138.18

FW2:
External Interface Reth0.0 = 10.99.132.18
Internal Interface Reth1.0 = 10.99.136.18

VPN will be built between FW1 and FW2. Firewall Policy will use VPN tunnel for traffic between 10.94.138.0/24 and 10.99.136.0/24

We will generate traffic between two machines 10.94.138.21 and 10.99.136.16 to test this vpn configuration on FW1 and FW2.

Step 1: routing between 10.94.132.18 and 192.168.9.18

@FW1:
admin@fw1> show configuration routing-options
static {
    route 0.0.0.0/0 next-hop 10.94.12.1;   /* this is fxp0.0 mgmt interface*/
    route 10.99.132.0/24 next-hop 192.168.9.1;   /* this route added to reach vpn peer gateway*/
}

@FW2
admin@fw2> show configuration routing-options 
static {
    route 0.0.0.0/0 next-hop 10.99.12.1;
    route 192.168.9.0/24 next-hop 10.99.132.1;
}

Step 2: Phase 1 IKE configuration

@FW1:

ike {

    proposal ike-p1-proposal {
        authentication-method pre-shared-keys;
        dh-group group2;
        authentication-algorithm sha1;
        encryption-algorithm aes-128-cbc;
    }
    policy ike-p1-policy {
        mode main;
        proposals ike-p1-proposal;
        pre-shared-key ascii-text "$9$O/-1REyXxdsgJSds2gJZn/9p1RylK"; ## SECRET-DATA
    }
    gateway gw-montreal-pin {        
        ike-policy ike-p1-policy;
        address 10.99.132.18;
        external-interface reth0.0;
    }
}
@FW2

ike {

    proposal ike-p1-proposal {
        authentication-method pre-shared-keys;
        dh-group group2;
        authentication-algorithm sha1;
        encryption-algorithm aes-128-cbc;
    }
    policy ike-p1-policy {
        mode main;
        proposals ike-p1-proposal;
        pre-shared-key ascii-text "$9$MkgXxdaJDmT7-Dk.mTQEcSe8Xdbs"; ## SECRET-DATA
    }
    gateway gw-k-pin {          
        ike-policy ike-p1-policy;
        address 192.168.9.18;
        external-interface reth0.0;
    }
}

Step 3: Phase 2 IPSec configuration

@FW1:

ipsec {

    proposal ipsec-p1-proposal {
        protocol esp;
        authentication-algorithm hmac-sha-256-128;
        encryption-algorithm aes-128-cbc;
        lifetime-seconds 3600;
    }
    policy ipsec-p2-policy {
        perfect-forward-secrecy {
            keys group2;
        }
        proposals ipsec-p1-proposal;
    }
    vpn ike-vpn-m {
        ike {
            gateway gw-m-pin;
            ipsec-policy ipsec-p2-policy;
        }
    }
}

@FW2

ipsec {

    proposal ipsec-p1-proposal {
        protocol esp;
        authentication-algorithm hmac-sha-256-128;
        encryption-algorithm aes-128-cbc;
    }
    policy ipsec-p2-policy {
        perfect-forward-secrecy {
            keys group2;
        }
        proposals ipsec-p1-proposal;
    }
    vpn ike-vpn-k {
        ike {
            gateway gw-k-pin;
            ipsec-policy ipsec-p2-policy;
        }
    }
}

Step 4: Policy Configuration

@FW1:
    from-zone T to-zone D {
        policy p-vpn-1 {
            match {
                source-address n_10.94.138.0-24;
                destination-address n_10.99.136.0-24;
                application any;
            }
            then {
                permit {
                    tunnel {
                        ipsec-vpn ike-vpn-m;
                        pair-policy p-vpn-2;
                    }
                    application-services {
                        idp;
                    }
                }
                log {
                    session-close;
                }
            }
        }
        policy 7 {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                deny;
            }
        }
    }
    from-zone D to-zone T {
        policy p-vpn-2 {
            match {
                source-address n_10.99.136.0-24;
                destination-address n_10.94.138.0-24;
                application any;
            }
            then {
                permit {
                    tunnel {
                        ipsec-vpn ike-vpn-m;
                        pair-policy p-vpn-1;
                    }
                    application-services {
                        idp;
                    }
                }
                log {
                    session-close;
                }
            }
        }
        policy 9 {
            match {
                source-address any;
                destination-address any;
                application any;
            }
            then {
                deny;
            }
        }
    }
}

@FW2

from-zone D to-zone P {
    policy p-vpn-1 {
        match {
            source-address n_10.94.138.0-24;
            destination-address n_10.99.136.0-24;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn ike-vpn-markham;
                    pair-policy p-vpn-2;
                }
            }
        }
    }
    policy 3 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}
from-zone P to-zone D {
    policy p-vpn-2 {
        match {
            source-address n_10.99.136.0-24;
            destination-address n_10.94.138.0-24;
            application any;
        }
        then {
            permit {
                tunnel {
                    ipsec-vpn ike-vpn-markham;
                    pair-policy p-vpn-1;
                }
            }
        }
    }
    policy 4 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}

Verification:

Ping between 10.99.136.16 and 10.94.138.21 is not working. That means unfortunately with those above configuration, the vpn tunnel is still not able up.

Troubleshooting:

admin@SRX-fw2# show | compare    
[edit security]
+   flow {
+       traceoptions {
+           file J1;
+           flag basic-datapath;
+           packet-filter Match-Traffic {
+               source-prefix 10.99.136.9/32;
+               destination-prefix 10.94.138.21/32;
+           }
+       }
+   }

admin@SRX-fw2# run show log J1
Aug 14 21:37:46 21:37:46.231681:CID-1:RT:filter 1 name Match-Traffic2 is set
Aug 14 21:37:46 21:37:46.231068:CID-1:CTRL:flow1: Rate limit changed to 0
Aug 14 21:37:46 21:37:46.231561:CID-1:CTRL:flow11: Destination ID set to 2
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:<10.99.136.9/1->10.94.138.21/50019;1> matched filter Match-Traffic:
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:packet [72] ipid = 50020, @0x436a041cAug 14 21:37:55 21:37:55.341589:CID-2:RT:---- flow_process_pkt: (thd 3): flow_ctxt type 15, common flag 0x0, mbuf 0x436a0200, rtbl_idx = 0Aug 14 21:37:55 21:37:55.341589:CID-2:RT: flow process pak fast ifl 68 in_ifp reth1.0
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:  reth1.0:10.99.136.9->10.94.138.21, icmp, (8/0)
Aug 14 21:37:55 21:37:55.341589:CID-2:RT: find flow: table 0x59b36da8, hash 34415(0xffff), sa 10.99.136.9, da 10.94.138.21, sp 1, dp 50019, proto 1, tok 7
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:  flow_first_create_session
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:  flow_first_in_dst_nat: in <reth1.0>, out <N/A> dst_adr 10.94.138.21, sp 1, dp 50019                      
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:  chose interface reth1.0 as incoming nat if.
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 10.94.138.21(50019)
Aug 14 21:37:55 21:37:55.341589:CID-2:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 10.99.136.9, x_dst_ip 10.94.138.21, in ifp reth1.0, out ifp N/A sp 1, dp 50019, ip_proto 1, tos 0
Aug 14 21:37:55 21:37:55.341890:CID-2:RT:Doing DESTINATION addr route-lookup
                                     
Aug 14 21:37:55 21:37:55.341916:CID-2:RT:  routed (x_dst_ip 10.94.138.21) from P (reth1.0 in 1) to fxp0.0, Next-hop: 10.99.12.1
                                     
Aug 14 21:37:55 21:37:55.341916:CID-2:RT:  packet dropped, out_ifp is null or in null-zone               
Aug 14 21:37:55 21:37:55.341961:CID-2:RT:Out-ifp fxp0.0 is null or in null zone
Aug 14 21:37:55 21:37:55.341961:CID-2:RT:  flow find session returns error.
Aug 14 21:37:55 21:37:55.341961:CID-2:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)
Aug 14 21:37:55 21:37:55.814250:CID-2:RT:jsf sess close notify                          
Aug 14 21:37:55 21:37:55.814302:CID-2:RT:flow_ipv4_del_flow: sess 69453, in hash 32
Aug 14 21:37:55 21:37:55.814315:CID-2:RT:ha_ifp: fxp0.0
Aug 14 21:38:04 21:38:04.521249:CID-2:RT:<10.99.136.9/0->10.94.138.21/1024;1> matched filter Match-Traffic:
Aug 14 21:38:04 21:38:04.521249:CID-2:RT:packet [84] ipid = 9853, @0x4368eb9c

It obviously the packets went out through fxp0.0. Basic my previous post How Firewalls (Security Gateways) Handle the Packets? (Traffic Flow) , for Juniper SRX firewall Routing Lookup happens before policy.
In this case, before vpn policy is able to get packets into vpn tunnel , the packets went out firewall fxp0.0 interface by default route.

admin@fw2# run show route
inet.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 1d 06:08:38
                    > to 10.99.12.1 via fxp0.0
10.99.12.0/24      *[Direct/0] 1d 06:08:38
                    > via fxp0.0
                    [Direct/0] 1d 06:08:38
                    > via fxp0.0
10.99.12.10/32     *[Local/0] 1d 06:08:38
                      Local via fxp0.0
10.99.12.15/32     *[Local/0] 1d 06:08:38
                      Local via fxp0.0
10.99.132.0/24     *[Direct/0] 1d 06:08:38
                    > via reth0.0
10.99.132.18/32    *[Local/0] 1d 06:08:38
                      Local via reth0.0
10.99.136.0/24     *[Direct/0] 1d 06:08:38
                    > via reth1.0
10.99.136.18/32    *[Local/0] 1d 06:08:38
                      Local via reth1.0
192.168.9.0/24     *[Static/5] 06:31:41
                    > to 10.99.132.1 via reth0.0

Solutions:

At this moment, firewall only has one specific route for peer gateway. Another specific static route will be added to route interesting  traffic through external interface.

admin@fw2# show
static {
    route 0.0.0.0/0 next-hop 10.99.12.1;
    route 192.168.9.0/24 next-hop 10.99.132.1;
}

john@fw-m-pin-b# set static route 10.94.138.0/24 next-hop 10.99.132.1

After added this route, tunnel is up right away when testing with interesting traffic.

{primary:node1}
john@fw-m-pin-b> show security ike security-associations
node1:
--------------------------------------------------------------------------
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
11102161 UP    5184a7627510f777  bba6d0242cb15a30  Main           192.168.9.18  

admin@fw2> show security ipsec security-associations
node1:
--------------------------------------------------------------------------
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway
  <2    ESP:aes-128/sha256 1cca52a5 3567/ unlim -  root 500   192.168.9.18  
  >2    ESP:aes-128/sha256 30b03088 3567/ unlim -  root 500   192.168.9.18  

Reference:

1. Using PKI Build Route-Based IPSec VPN between Juniper SRX
2. Configuration Examples: Policy-based VPN


Friday, January 16, 2015

Using PKI Build Route-Based IPSec VPN between Juniper SRX

There was a task to change IPSec authentication method from Pre-share key to PKI Certification based. It used on SRX240H and SRX1400 firewalls. This post records the steps and troubleshooting the errors I met during the configuration.

1. On both firewalls generate Public/Private key pair:

{primary:node0}root@fw-1> request security pki generate-key-pair certificate-id PRO size 2048   
node0:
--------------------------------------------------------------------------
Generated key pair PRO, key size 2048 bits

2. Generating cert request from the key pair

{primary:node0}root@fw-1> request security pki generate-certificate-request certificate-id PRO subject "CN=Admin,CN=m.test.com,OU=IT,O=test,L=M,ST=ON,C=CA" email admin@test.com filename ms-cert-req 
node0:
--------------------------------------------------------------------------Generated certificate request
----- BEGIN CERTIFICATE REQUEST-----MIIC7TCCAdUCAQAwdjERMA8GA1UEAxMISm9obiBZYWxGjAYBgNVBAMTEW1hcmtYW0uZ2ktZGUuY29tMQswCQYDVQQLEwJJVDEMMAoGA1UEChMDRyZEwDgYDVQQEwdNYXJraGFtMQswCQYDVQQIEwJPTjELMAkGA1UEBhMC0EwggEiMA0GCSqGSIbDQEBAQUAA4IBDwAwggEKAoIBAQDEoahBD7RjFBZacquplzFudJ3k+jf1EBcCxxkdDWJVeZEDzFMN6kQbMPKFBvSHhSZU/o+AnkqOzQgTh9Uy/ttdc3r23ZWFu1t/9B79kvoRdxCt43iYHNtTyKk4xN1/Nd2XJ1qV6iXB0OAYAQWnKYsNAz5rY9SRnH5/VU90WRvu5s/wXu+9GEoysI1sjm91Qq1FM5HDtH9ROxDzbtEb8hJ2SmfY/VPctlSI/Ql3ZRyxCexOG2Q93hvhMRKbCNLxj1muSHbnveQI3gM+4nT9PmslUEB3dx5389LH5viCio01039LEWjfydd4HsAdsgD5ZXtihn49BPZNfCIYyDAgMBAAGgMjAwBgkhkiG9w0BCQ4xIzAhMB8GA1UdEQQYMBaBFCJqb2huLnlhbkBnaS1kZS5jb20iMA0CSqGSIb3DQEBBQUAA4IBAQAoRv0I1C5kklU2sRDGB4XCVnnJ/T34+Yn4ekIcGHADuB5kKbr+qc1xTVyelX09EqmGtCrREYSv/meseuco0+jMw9b9EogCfE7eZAw2EWltzA+NTjwcOexvTFYWhjD3YWPXwM/F/rKnS9vtCaaNJB+rpzjyjbJNRSPvFkYgRUsy3xnIJ7K76Jp03r5rD27KW2kaCCD2wXkr6vK97Nf+dgyM8sLBLy1FdUfeO2H5JnhxbodUD6FFGz50s8rqy2a4aUOCD1zCgOiMw/mjq3caFbS+WB2sb+09Kia19y9y2fOzG++v2Kud5luXYKMPuf4qEGSb6k1npNd8qadQf+
-----END CERTIFICATE REQUEST----- 
Fingerprint:c7:dd:83:11:d1:8a:54:6c:5c:1e:7e:cd:79:73:c0:71:b0:ba:a5:fc (sha1)f6:10:e3:1f:c0:07:3e:dc:5c:e5:8e:b5:51:2b:9a:1e (md5)

3. Submit Cert Request to the CA and Retrieve Certs






4. Copying the Local Cert, CA Cert to local firewall


You can either use ftp to transfer file to local devices or using vi to copy/paste cert into local folder just like it shows below:
root@fw-1% cd /var/tmp
root@fw-1% vi cert.cer

-----BEGIN CERTIFICATE-----
MIIFAjCCA+qgAwIBAgIQLW8DBB6T4el6zXWK6UDm2zANBgkqhkiG90BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE1MDEwOTAwMDAwMFoX
DTE4MDQwNTIzNTk1OVowgYwxCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdPbnRhcmlv
MRAwDgYDVQQHDAdNYXJraGFtMS8wLQYDVQQKDCZHaWVzZWNrZSAmIERldnJpZW50
IFN5c3RlbXMgQ2FuYWRhIEluYzELMAkGA1UECwwCSVQxGzAZBNVBAMMEm1vbnRy
ZWFsLmdpLWRlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ2W
x3bDZiXD7Fhh7smdgq7W3ib/UOixoM7NDxryWVaff0mq3oioXUxpClvwkadJ5Js7
3+QOJH0j/jJLwJ6mN/8Me64Caxy3fHkp43NNTz1aOEr2QwOLuY4Z6rvNUgBdqLWo
OpI8OAYTMlBWMT++aKK35PAtDKLxCyKz6iqeR3tbqsxDnfJO5YafyDf8AtRmNJPg
1ms1yV0lKZBtq4weAKHLeSe0+SYu5CIgKHDhUbZ9SjQHyaNpSSY0agtm7gwppcYU
BPtkSTFyyxAVxMQrZrOMPSF2ND1qgwtQkv4ypAx70oLSP2FjWYxXS8eZCaBXRWzp
+2Q0gEbcQ85NG9DZCuMCAwEAAaOCAWswggFnMB0GA1UdEQQWMBSCEm1vbnRyZWFs
LmdpLWRlLmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDArBgNVHR8EJDAi
MCCgHqAchhpodHRwOi8vc3Muc3ltY2IuY29tL3NzLmNybDBlBgNHSAEXjBcMFoG
CmCGSAGG+EUBBzYwTDAjBggrBgEFBQcCARYXaHR0cHM6Ly9kLnN5bWNiLmNvbS9j
cHMwJQYIKwYBBQUHAgIwGQwXaHR0cHM6Ly9kLnN5bWNiLmNvbS9ycGEwHQYDVR0l
BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1UdIwQYMaAFF9gz2GQVd+EQxSK
YCqy9Xr0QxjvMFcGCCsGAQUFBwEBBEswSTAfBggrBgEFBQcwAYYTaHR0cDovL3Nz
LnN5bWNkLmNvbTAmBggrBgEFBQcwAoYaaHR0cDovL3NzLnN5bWNiLmNvbS9zcy5j
cnQwDQYJKoZIhvcNAQELBQADggEBAGSmIK5nDbs0e1aryWxbrCp9vMC7dTiJYP9
7VlUZsP63WXTWmOs1CBcyxv1NiO2Ub+CgiynAjnBKzDjPM8EesaTLlHnFqjRD65d
jXwa5UnlQnuZLzdadThp2qmhQbTeGBmT/y4c3rSwHnXwjB0aMQzz7QrKEmNrv13o
2eYEMp2tvZVSemPWpABj265tu6RcD6If3oTxKJy10/pKA/YU3xRLL9XB3NvU5NUO
Ej7ubdQsBTTBeJIE8/C5coDLEZbxYpQVSnqDBrOXLG5R2pNi0hIebXFaVDG36gy
NCGfTTNr8Elo7RYMspaZZhyQRZzXefzCxJwqxu39MwTNRJAhTPA=
-----END CERTIFICATE-----

root@fw-1% vi root.cer
-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIQUT+5dDhwtzRAQY0wkwaZ/zANBgkqhkiG9w0BAQsFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTMxMDMxMDAwMDAwWhcNMjMxMDMwMjM1OTU5WjB+MQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV
BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVjIENs
YXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAstgFyhx0LbUXVjnFSlIJluhL2AzxaJ+aQihiw6UwU35VEYJb
A3oNL+F5BMm0lncZgQGUWfm893qZJ4Itt4PdWid/sgN6nFMl6UgfRk/InSn4vnlW
9vf92Tpo2otLgjNBEsPIPMzWlnqEIRoiBAMnF4scaGGTDw5RgDMdtLXO637QYqzu
s3sBdO9pNevK1T2p7peYyo2qRA4lmUoVlqTObQJUHypqJuIGOmNIrLRM0XWTUP8T
L9ba4cYY9Z/JJV3zADreJk20KQnNDz0jbxZKgRb78oMQw7jW2FUyPfG9D72MUpVK
Fpd6UiFjdS8W+cRmvvW1Cdj/JwDNRHxvSz+w9wIDAQABo4IBYzCCAV8wEgYDVR0T
AQH/BAgwBgEB/wIBADAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vczEuc3ltY2Iu
Y29tL3BjYTMtZzUuY3JsMA4GA1UdDwEB/wQEAwIBBjAvBggrBgEFBQcBAQQjMCEw
HwYIKwYBBQUHMAGGE2h0dHA6Ly9zMi5zeW1jYi5jb20wawYDVR0gBGQwYjBgBgpg
hkgBhvhFAQc2MFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v
Y3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMCkG
A1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0xLTUzNDAdBgNVHQ4E
FgQUX2DPYZBV34RDFIpgKrL1evRDGO8wHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnz
Qzn6Aq8zMTMwDQYJKoZIhvcNAQELBQADggEBAF6UVkndji1l9cE2UbYD49qecxny
H1mrWH5sJgUs+oHXXCMXIiw3k/eG7IXmsKP9H+IyqEVv4dn7ua/ScKAyQmW/hP4W
Ko8/xabWo5N9Q+l0IZE1KPRj6S7t9/Vcf0uatSDpCr3gRRAMFJSaXaXjS5HoJJtG
QGX0InLNmfiIEfXzf+YzguaoxX7+0AjiJVgIcWjmzaLmFN5OUiQt/eV5E1PnXi8t
TRttQBVSK/eHiXgSgW7ZTaoteNTCLD0IX4eRnh8OsN4wUmSGiaqdZpwOdgyA8nTY
Kvi4Os7X1g8RvmurFPW9QaAiY4nxug9vKWNmLT+sjHLF+8fk1A/yO0+MKcc=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE0DCCBDmgAwIBAgIQJQzo4DBhLp8rifcFTXz4/TANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDYxMTA4MDAwMDAwWhcNMjExMTA3MjM1OTU5WjCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1nmAMqudLO07cfLw8
RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbext0uz/o9+B1fs70Pb
ZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIzSdhDY2pSS9KP6HBR
TdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQGBO+QueQA5N06tRn/
Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+rCpSx4/VBEnkjWNH
iDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/NIeWiu5T6CUVAgMB
AAGjggGbMIIBlzAPBgNVHRMBAf8EBTADAQH/MDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA4GA1UdDwEB/wQEAwIBBjA9
BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL2NwczAdBgNVHQ4EFgQUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwbQYI
KwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQU
j+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVyaXNpZ24uY29t
L3ZzbG9nby5naWYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC52ZXJpc2lnbi5jb20wPgYDVR0lBDcwNQYIKwYBBQUHAwEGCCsGAQUFBwMC
BggrBgEFBQcDAwYJYIZIAYb4QgQBBgpghkgBhvhFAQgBMA0GCSqGSIb3DQEBBQUA
A4GBABMC3fjohgDyWvj4IAxZiGIHzs73Tvm7WaGY5eE43U68ZhjTresY8g3JbT5K
lCDDPLq9ZVTGr0SzEK0saz6r1we2uIFjxfleLuUqZ87NMwwq14lWAyMfs77oOghZ
tOxFNfeKW/9mz1Cvxm1XjRl4t7mi0VfqH5pLr7rJjhJ+xr3/
-----END CERTIFICATE-----

5. Creating a Trusted CA Profile and load local certificate and CA Certificate

ca-profile rootverisign {
    ca-identity test.com;
    revocation-check {
        disable;
    }
    administrator {
        email-address "admin@test.com";
    }
 }

{primary:node0}root@fw-1> request security pki local-certificate load certificate-id PRO filename /var/tmp/cert.cer
node0:
--------------------------------------------------------------------------
Local certificate loaded successfully

{primary:node0}root@fw-1> request security pki ca-certificate load ca-profile rootverisign filename /var/tmp/root.cer
node0:
--------------------------------------------------------------------------
error: Command aborted as CA certificate already exists. Retry after clearing the existing CA certificate
This error is relating to existing CA certificate. We will clear it first by following command:
{primary:node0}
root@fw-1> clear security pki ca-certificate ca-profile rootverisign 
or You can directly go into cert folder to delete it.
root@fw-1> request security pki ca-certificate load ca-profile Montreal-PRO filename /var/tmp/root.cer 
node0:
--------------------------------------------------------------------------
Fingerprint:
  44:f4:34:20:3e:fa:be:7e:9e:c5:82:94:e3:b2:36:0b:4c:c5:c0:c0 (sha1)
  1a:3e:85:80:2b:c7:57:86:c2:44:66:ff:89:ad:1e:c8 (md5)
error: Failed to write the CA certificate to local store

This error message usaully caused by unrecognized certificate file format. Actually, Juniper SRX does not take this kind of CA certification which has two certifications inside one file. We have to manually split this Certification to two parts then separately import different CA Profile, such as G4 and G5 we created below.
pki {
    ca-profile G4 {
        ca-identity gi-de.com;
        revocation-check {
            disable;
        }
        administrator {
            email-address "admin@test.com";
        }
    }
    ca-profile G5 {
        ca-identity gi-de.com;
        revocation-check {
            disable;
        }
        administrator {
            email-address "admin@test.com";
        }
    }
    traceoptions {
        file PKITRACE size 1m;
        flag all;
    }
}
root@fw-1> request security pki ca-certificate load ca-profile G4 filename /var/tmp/g4.cer 
node0:
--------------------------------------------------------------------------
Fingerprint:
  ff:67:36:7c:5c:d4:de:4a:e1:8b:cc:e1:d7:0f:da:bd:7c:86:61:35 (sha1)
  23:d5:85:8e:bc:89:86:10:7c:b7:ac:1e:17:f7:26:c5 (md5)
CA certificate for profile G4 loaded successfully

{primary:node0}
root@fw-1> request security pki ca-certificate load ca-profile G5 filename /var/tmp/g5.cer    
node0:
--------------------------------------------------------------------------
Fingerprint:
  32:f3:08:82:62:2b:87:cf:88:56:c6:3d:b8:73:df:08:53:b4:dd:27 (sha1)
  f9:1f:fe:e6:a3:6b:99:88:41:d4:67:dd:e5:f8:97:7a (md5)
CA certificate for profile G5 loaded successfully

6. Using the Cert in IPsec VPN Configuration

ike {
    inactive: traceoptions {
        file IKELOG size 1m;
        flag policy-manager;
        flag ike;
        flag routing-socket;
        flag certificates;
    }
    proposal P1-AES_1_1_1 {
        authentication-method rsa-signatures;
        dh-group group2;
        authentication-algorithm sha1;
        encryption-algorithm aes-128-cbc;
        lifetime-seconds 86400;
    }
    policy ike-pol-Myvpn {
        mode main;
        proposals P1-AES_1_1_1;
        certificate {
            local-certificate Mark-PRO;
            peer-certificate-type x509-signature;
        }
        inactive: pre-shared-key ascii-text "$9$4xZGjqmT3nCHqp01IcSs2g4Uj"; ## SECRET-DATA
    }
    gateway gw-TheirGateway {
        ike-policy ike-pol-Myvpn;
        address 10.9.1.1;
        local-identity hostname mark.test.com;
        remote-identity hostname mont.test.com;
        external-interface reth9.0;
        local-address 10.4.1.1;
    }
}
ipsec {
    proposal P2-AES_1 {
        description group2;
        protocol esp;
        authentication-algorithm hmac-sha1-96;
        encryption-algorithm aes-128-cbc;
        lifetime-seconds 3600;
    }
    policy ipsec-pol-1 {
        perfect-forward-secrecy {
            keys group2;
        }
        proposals P2-AES_1;
    }
    vpn vpn-ToThem {
        bind-interface st0.0;
        ike {
            gateway gw-TheirGateway;
            idle-time 1800;
            ipsec-policy ipsec-pol-1;
        }
    }

}

Some Other Configuration for Route-Based IPSec VPN

Interfaces {
    st0 {
        unit 0 {
            family inet;
        }
    }
}

admin@fw-trn1-2> show configuration routing-instances 
vr_SRX2{
    instance-type virtual-router;
    interface reth9.0;
    interface st0.0;
    routing-options {
        static {
            route 1.1.1.0/24 next-hop 10.4.1.2;
            route 10.9.0.0/16 next-hop st0.0;
            route 10.9.1.1/32 next-hop 10.4.1.2;
        }
        aggregate {
            route 10.94.0.0/16 {
                preference 2;
            }
            route 192.168.0.0/16 {
                preference 2;
            }
        }
        instance-import from_all_to_SRXl;
    }


Reference:

1. Commands to clear pki related files

  • clear security pki key-pair certificate-id Markham-PRO
  • clear security pki local-certificate certificate-id Markham-PRO
  • clear security pki key-pair certificate-id Markham-PRO
  • clear security pki ca-certificate ca-profile Markham-PRO
  • clear security pki certificate-request certificate-id Markham-PRO
2. J Series / SRX Series IPSec VPN with PKI Certificates Primer
3. Example: Configuring the PKI in Junos OS
4. Certificate based IPSEC VPN in SRX
5. Juniper SRX - PKI - Certificate-based VPNs - Part 02 - SRX Configuration & Certificate Signings

Notes:

The following will setup your installed SSL certificate on fe-0/0/0.0 You need to assign this to the
externally facing interface. The interface should be set to accept HTTPS.

set security zones security-zone untrust interfaces fe-0/0/0.0 host-inbound-traffic systemservices https
set system services web-management https pki-local-certificate PRO interface fe-0/0/0.0

Monday, December 15, 2014

Certificate Import Failed with "% Failed to parse or verify imported certificate" because of Verisign Using new Intermediate CA Certs G4

Symptoms:

Worked on IPSec VPN Certificate for whole morning to try to import a certificate, finally gave up to ask support from Verisign. I did this many times and had detailed documentation recorded for steps. But this time, situation is different. 

My previous post clearly shows all steps I have to follow:
Unfortunately, this time the process stuck at the step 6 with error "% Failed to parse or verify imported certificate"

m-dmz(config)#crypto pki import VerisignCA1 certificate 

Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself

000158: Dec 15 12:38:30.479 EST: CRYPTO_PKI: using private key v-dmz-mto.gi-de.com for enrollment
-----BEGIN CERTIFICATE-----
MIIE9zCCA9+gAwIBAgIQCIftKcaj6IyeTvfUlyuOzANBgkqhkiG9w0BAQsFADB+
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVj
IENsYXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MB4XDTE0MTIxNTAwMDAwMFoX
DTE3MDMxMjIzNTk1OVowgYAxCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdvbnRhcmlv
MRAwDgYDVQQHDAdtYXJraGFtMS8wLQYDVQQKDCZHaWVzZWNrZSAmIERldnJpZW50
IHN5c3RlbXMgY2FuYWRhIGluYzEcMBoGA1UEAwwTVi1ETVotTVRPLmdpLWRlLmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMY2d63D++tY3UJHi0hT
POYtTGT1vqLXgbpne4LkSsGyD/ehWiJe6jmPAzoLDPBpznIlW/DPKd63ABr/333
HNrFRDi3caYJqYjASH9M0ujJPigWVtbaLNBA+LsnmAd6m4IRXC8Q5lkrrl3nEcr/
h0uD9iHC76tz8ZwjNMonda8JEvVaqvqeXwk6CTfxzBPJ/Lwz5QpS7I9vFhzQqXea
+R8nGAl0ES3QRkWKIoBthP70FnLiy+0LawkWwFWZHW/aDwjMeXEQg24eRjeqAk0
H3ysSVc2f+2AydAtXmvStUmcr9R/2y3d8AJeFzqoHx+9kgHk21ozjTRn0uj6XmTO
p6UCAwEAAaOCAWwwggFoMB4GA1UdEQQXMBWCE1YtRE1aLU1UTy5naS1kZS5jb20w
CQYDVR0TBAIwADAOBgNVHQ8BAf8EBMCBaAwKwYDVR0fBCQwIjAgoB6gHIYaaHR0
cDovL3NzLnN5bWNiLmNvbS9zcy5jcmwwZQYDVR0gBF4wXDBaBgpghkgBhvhFAQc2
MEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20vY3BzMCUGCCsGAQUF
BwICMBkMF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMB0GA1UdJQQWMBQGCCsGAQUF
BwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBRfYM9hkFXfhEMUimAqsvV69EMY7zBX
BggrBgEFBQcBAQRLMEkwHwYIKwYBBQUHMAGGE2h0dHA6Ly9zcy5zeW1jZC5jb20w
JgYIKwYBBQUHMAKGGmh0dHA6Ly9zcy5zeW1jYi5jb20vc3MuY3J0MA0GCSqGSIb3
DQEBCwUAA4IBAQBbgmnEA7ERTeKDTYT9gxc1A2+TliCHODGGQ8deEFrBySbKOdIN
X+Au6Jk0leWHr1sjcVwJlNZLwDKJZcs0d78JXJRDi1kfoFxcehMkNi3hzMm/78lW
WNujf4On8faQTjPJz9Zqi6vr/1OnSwNVlrudeFX05chHygRuSy9hewSf5bIFp5TG
iA0jhzbe+D8+kbhLhb5m+VI2JZ338/hE7JcNGJOIXhjyKyZeafJqLi9nlfg8Pb9o
i1oQV9SxGuTkjYmRmVx8+gknQCIIGXcVlT2jXZDKyHaeReVpUFGBVOvyzFulVfOx
dVtUsyu4UHi3p8N2BfUlUt0JrRREyN68Fnos
-----END CERTIFICATE-----

% Failed to parse or verify imported certificate

By enabling following debug, I got some more details show "valid cert path not found"

debug crypto pki messages
debug crypto pki transactions
debug crypto pki validation

Dec 15 17:25:18.264: CRYPTO_PKI: make trustedCerts list for VerisignCA1
Dec 15 17:25:18.264: CRYPTO_PKI: subject="cn=VeriSign Class 3 Secure Server CA - G3,ou=Terms of use at https://www.verisign.com/rpa (c)10,ou=VeriSign Trust Network,o=VeriSign, Inc.,c=US" serial number= 6E CC 7A A5 A7 03 20 09 B8 CE BC F4 E9 52 D4 91 n.z... ......R..
Dec 15 17:25:18.272: ../VIEW_ROOT/cisco.comp/pki_ssl/src/ca/provider/path/pkix/pkixpath.c(1364) : E_PATH_NOT_FOUND : valid cert path not found (reason: 18)
Dec 15 17:25:18.272: CRYPTO_PKI: status = 0x750(E_PATH_NOT_FOUND : valid cert path not found (reason: %n0)): failed to verify or insert the cert into storage

m-dmz(config)#crypto pki certificate validate VerisignCA1
Validation Failed: can't get local certificate chain


I even tried following method which I googled from Internet. I created multiple Trustpoint just in case I missed a root certificate since I were only using one 'RSA Secondary SSL Intermediate CA Certificate' in Symantec Article AR2108, which I tested it before and was working.

"I ended up using the following order based on the digicert tutorial to complete the install.  The trick is to have an empty first trust point, which has the first intermediate cert, and a second trust point using the "chain-validation continue [FirstTrustpointName]" with the second intermediate certificate and the ssl cert.

crypto ca trustpoint VPN-Trustpoint
enrollment terminal pem
rsakeypair vpn-sslkey
exit

crypto ca trustpoint VPN-Trustpoint-2
enrollment terminal pem
crl optional
subject-name CN=vpn.org,OU=IT,O=Org,C=US,ST=NY,L=City
fqdn vpn..org
rsakeypair vpn-sslkey
chain-validation continue VPN-Trustpoint
exit

crypto ca enroll VPN-Trustpoint-2

crypto ca authenticate VPN-Trustpoint
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
quit

crypto ca authenticate VPN-Trustpoint-2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
quit

crypto ca import VPN-Trustpoint-2 certificate
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
quit

webvpn gateway gateway_1
ssl trustpoint VPN-Trustpoint-2
end
"

Solution:

After I gave up my troubleshooting and gave a Verisign support a call, the mystery is resolved with a clear and simple cause. Symantec is using a new Intermediate CA G4 for new certificate with Signature hash algorithm: SHA-256 shows below. Verisign did not update their Article for the link to this new Intermediate CA yet. But you will get it when download your certificate from your account.



You will get a zip file includes following files:
ssl_certificate.crt is your ssl certificate. IntermediateCA.crt is the new G4 certificate. Previous one in the article AR2108 is G3 and G5. I was able to use G3 only to get certificate imported and validated in my previous post 
I copied new Intermediate G4 certificate at below for future reference, although feel disappointed for Verisign not able to update their website and not email right thing to customer. Hopefully it is only me to have this pain. 

-----BEGIN CERTIFICATE-----
MIIFODCCBCCgAwIBAgIQUT+5dDhwtzRAQY0wkwaZ/zANBgkqhkiG9w0BAQsFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTMxMDMxMDAwMDAwWhcNMjMxMDMwMjM1OTU5WjB+MQsw
CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV
BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxLzAtBgNVBAMTJlN5bWFudGVjIENs
YXNzIDMgU2VjdXJlIFNlcnZlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAstgFyhx0LbUXVjnFSlIJluhL2AzxaJ+aQihiw6UwU35VEYJb
A3oNL+F5BMm0lncZgQGUWfm893qZJ4Itt4PdWid/sgN6nFMl6UgfRk/InSn4vnlW
9vf92Tpo2otLgjNBEsPIPMzWlnqEIRoiBAMnF4scaGGTDw5RgDMdtLXO637QYqzu
s3sBdO9pNevK1T2p7peYyo2qRA4lmUoVlqTObQJUHypqJuIGOmNIrLRM0XWTUP8T
L9ba4cYY9Z/JJV3zADreJk20KQnNDz0jbxZKgRb78oMQw7jW2FUyPfG9D72MUpVK
Fpd6UiFjdS8W+cRmvvW1Cdj/JwDNRHxvSz+w9wIDAQABo4IBYzCCAV8wEgYDVR0T
AQH/BAgwBgEB/wIBADAwBgNVHR8EKTAnMCWgI6Ahhh9odHRwOi8vczEuc3ltY2Iu
Y29tL3BjYTMtZzUuY3JsMA4GA1UdDwEB/wQEAwIBBjAvBggrBgEFBQcBAQQjMCEw
HwYIKwYBBQUHMAGGE2h0dHA6Ly9zMi5zeW1jYi5jb20wawYDVR0gBGQwYjBgBgpg
hkgBhvhFAQc2MFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v
Y3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMCkG
A1UdEQQiMCCkHjAcMRowGAYDVQQDExFTeW1hbnRlY1BLSS0xLTUzNDAdBgNVHQ4E
FgQUX2DPYZBV34RDFIpgKrL1evRDGO8wHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnz
Qzn6Aq8zMTMwDQYJKoZIhvcNAQELBQADggEBAF6UVkndji1l9cE2UbYD49qecxny
H1mrWH5sJgUs+oHXXCMXIiw3k/eG7IXmsKP9H+IyqEVv4dn7ua/ScKAyQmW/hP4W
Ko8/xabWo5N9Q+l0IZE1KPRj6S7t9/Vcf0uatSDpCr3gRRAMFJSaXaXjS5HoJJtG
QGX0InLNmfiIEfXzf+YzguaoxX7+0AjiJVgIcWjmzaLmFN5OUiQt/eV5E1PnXi8t
TRttQBVSK/eHiXgSgW7ZTaoteNTCLD0IX4eRnh8OsN4wUmSGiaqdZpwOdgyA8nTY
Kvi4Os7X1g8RvmurFPW9QaAiY4nxug9vKWNmLT+sjHLF+8fk1A/yO0+MKcc=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIE0DCCBDmgAwIBAgIQJQzo4DBhLp8rifcFTXz4/TANBgkqhkiG9w0BAQUFADBf
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDMgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw
HhcNMDYxMTA4MDAwMDAwWhcNMjExMTA3MjM1OTU5WjCByjELMAkGA1UEBhMCVVMx
FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz
dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2lnbiwgSW5jLiAtIEZv
ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAz
IFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1nmAMqudLO07cfLw8
RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbext0uz/o9+B1fs70Pb
ZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIzSdhDY2pSS9KP6HBR
TdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQGBO+QueQA5N06tRn/
Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+rCpSx4/VBEnkjWNH
iDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/NIeWiu5T6CUVAgMB
AAGjggGbMIIBlzAPBgNVHRMBAf8EBTADAQH/MDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMuY3JsMA4GA1UdDwEB/wQEAwIBBjA9
BgNVHSAENjA0MDIGBFUdIAAwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVy
aXNpZ24uY29tL2NwczAdBgNVHQ4EFgQUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwbQYI
KwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQU
j+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVyaXNpZ24uY29t
L3ZzbG9nby5naWYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v
b2NzcC52ZXJpc2lnbi5jb20wPgYDVR0lBDcwNQYIKwYBBQUHAwEGCCsGAQUFBwMC
BggrBgEFBQcDAwYJYIZIAYb4QgQBBgpghkgBhvhFAQgBMA0GCSqGSIb3DQEBBQUA
A4GBABMC3fjohgDyWvj4IAxZiGIHzs73Tvm7WaGY5eE43U68ZhjTresY8g3JbT5K
lCDDPLq9ZVTGr0SzEK0saz6r1we2uIFjxfleLuUqZ87NMwwq14lWAyMfs77oOghZ
tOxFNfeKW/9mz1Cvxm1XjRl4t7mi0VfqH5pLr7rJjhJ+xr3/
-----END CERTIFICATE-----

By the way, if you have imported wrong Intermediate certificate, you do not have to delete trustpoint as shown on the cisco route

v-dmz(config)#crypto pki authenticate VerisignCA1 
% Please delete your existing CA certificate first.
% You must use 'no crypto pki trustpoint <trustpoint-name>' to delete the CA certificate.

I found it is working by just delete "crypto pki certificate chain VerisignCA1" with command 
v-dmz(config)#no crypto pki certificate chain VerisignCA1

Then you could re-import your intermediate certificate without remove your trustpoint. If you completely remove the trustpoint with Cisco's suggestion 'You must use 'no crypto pki trustpoint <trustpoint-name>' to delete the CA certificate.', you will have to end it up with re-create your trustpoint , your CSR and re-submit your CSR. That will take a long time to get your certificate from your CA.


m-dmz#sh crypto pki certificates 
Certificate
  Status: Available
  Certificate Serial Number (hex): 0887ED29C6A3E88C9E4EF7D4972BB43B
  Certificate Usage: General Purpose
  Issuer: 
    cn=Symantec Class 3 Secure Server CA - G4
    ou=Symantec Trust Network
    o=Symantec Corporation
    c=US
  Subject:
    Name: m-dmz.test.com
    cn=m-dmz.test.com
    o=Giesecke & Devrient systems canada inc
    l=markham
    st=ontario
    c=CA
  CRL Distribution Points: 
    http://ss.symcb.com/ss.crl
  Validity Date: 
    start date: 19:00:00 EST Dec 14 2014
    end   date: 19:59:59 EDT Mar 12 2017
  Associated Trustpoints: VerisignCA1 

CA Certificate
  Status: Available
  Certificate Serial Number (hex): 513FB9743870B73440418D30930699FF
  Certificate Usage: Signature
  Issuer: 
    cn=VeriSign Class 3 Public Primary Certification Authority - G5
    ou=(c) 2006 VeriSign
     Inc. - For authorized use only
    ou=VeriSign Trust Network
    o=VeriSign
     Inc.
    c=US
  Subject: 
    cn=Symantec Class 3 Secure Server CA - G4
    ou=Symantec Trust Network
    o=Symantec Corporation
    c=US
  CRL Distribution Points: 
    http://s1.symcb.com/pca3-g5.crl
  Validity Date: 
    start date: 20:00:00 EDT Oct 30 2013
    end   date: 19:59:59 EDT Oct 30 2023
  Associated Trustpoints: VerisignCA1 

Router Self-Signed Certificate
  Status: Available
  Certificate Serial Number (hex): 01
  Certificate Usage: General Purpose
  Issuer: 
    cn=IOS-Self-Signed-Certificate-1843068825
  Subject:
    Name: IOS-Self-Signed-Certificate-1843068825
    cn=IOS-Self-Signed-Certificate-1843068825
  Validity Date: 
    start date: 11:31:26 EDT Jul 28 2012
    end   date: 19:00:00 EST Dec 31 2019
  Associated Trustpoints: TP-self-signed-1843068825 
  Storage: nvram:IOS-Self-Sig#1.cer

Reference: