Certificate based IPSEC VPN in SRX

Here I will share how I have connected two SRX boxes via IPSEC VPN by using
certificate authentication instead of pre-shared key. Here is the outline;

1) Create certificate authority in Linux
2) Create CA profile on SRX
3) Generate Certificate Request
4) Sign the certificate
5) Load the certificates
6) Configure IPSEC/VPN
7) Verification

certificate_based_vpn_srx


1) Create certificate authority in Linux
I assume you have already openssl installed in your Linux host.

a) Create necessary directories for CA

#mkdir -p /etc/pki_srx/CA1/{private,certs,newcerts,crl}

b) Prepare SSL config

#cp  /etc/ssl/openssl.cnf /etc/pki_srx/CA1/openssl.srx.cnf
#chmod 600 /etc/pki_srx/CA1/openssl.srx.cnf
#touch /etc/pki_srx/CA1/index.txt
#echo '01' > /etc/pki_srx/CA1/serial

c) Create CA certificate and private key

#cd /etc/pki_srx/CA1/
#openssl req -config openssl.srx.cnf -new -x509 -extensions v3_ca -keyout private/ca.key -out certs/ca.crt -days 1500

d) Edit openssl.srx.cnf file

[ CA_default ]

dir             = .                     # <-----CHANGE THIS
certs           = $dir/certs            
crl_dir         = $dir/crl              
database        = $dir/index.txt       
#unique_subject = no                    
                                        
new_certs_dir   = $dir/newcerts         

certificate     = $dir/certs/ca.crt     # <------CHANGE THIS
serial          = $dir/serial           
crlnumber       = $dir/crlnumber        
                                        
crl             = $dir/crl.pem          
private_key     = $dir/private/ca.key   # <------CHANGE THIS
RANDFILE        = $dir/private/.rand    

2) Create a CA profile on SRX
All operations are done on host J24 and differences for J41 HUB device will be mentioned at the end of the post.

J24# set security pki ca-profile srx-ca ca-identity example.com
J24# set security pki ca-profile srx-ca revocation-check disable
J24# set security pki ca-profile srx-ca administrator email-address admin@example.com

3) Generate Certificate Request

a) Generate public/private key pair

root@J24> request security pki generate-key-pair certificate-id srx-j24-id size 1024     
Generated key pair srx-j24-id, key size 1024 bits

b) Generate cert request from this pair

J24>request security pki generate-certificate-request certificate-id srx-j24-id subject "CN=Mr. Admin,OU=SRX Dept,C=NL" domain-name j24.example.com filename srx-j24-req
Generated certificate request
-----BEGIN CERTIFICATE REQUEST-----
MIIBoTCCAQoCAQAwNDESMBAGA1UEAxMJTXIuIEFkbWluMREwDwYDVQQLEwhTUlgg
RGVwdDELMAkGA1UEBhMCTkwwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALuf
atlt5FlvnUHX+6XtHIyKMoDPh9K6gUlNPb4ZIAnNU1kPknDl/h6l17fPiqyUT+v6
eKNMcx0RyKShiDV3mtomJNFJf+wuvdZWHzXOtWnbujrAOJRHTCdSWTFOE4OANbPV
s6uL5cBemQoPM/iuX/t7zHb6qdeZZGV8NNdVcs4HAgMBAAGgLTArBgkqhkiG9w0B
CQ4xHjAcMBoGA1UdEQQTMBGCD2oyNC5leGFtcGxlLmNvbTANBgkqhkiG9w0BAQUF
AAOBgQCUAFZPxzTjDZNpaWl7gI0PoWVFeNUkeJAjxnNwEvtLpAhJ2OmV9JPYxfPN
kqCvPuqMX2MK/TrsWu9SaPt8mO6XvtxY9PAd8SjlrcJgWOr4rVZZm2cV+BsLu3yd
zxAwkTbEOCgaKV3F6vnOhdRnVu3/AZ65UjTj0ffkrNW6ZPQtCA==
-----END CERTIFICATE REQUEST-----
Fingerprint:
8b:6f:05:90:e1:61:bf:c0:04:c4:cc:32:be:c4:f9:97:e5:56:1d:18 (sha1)
ea:ed:f3:80:22:c7:2e:c1:68:20:79:29:6d:73:54:35 (md5)

Certificate request file is saved under : /cf/var/db/certs/common/certificate-request/srx-j24-id.req
Be careful domain-name j24.example.com is important. It will be used as the IKE-ID

4) Sign the certificate

a) Create a file named ext.cfg under /etc/pki_srx/CA1 with the following content

subjectAltName=DNS:j24.example.com

j24.example.com is our IKE-ID

b) Sign the certificate

#cd /etc/pki_srx/CA1/
#openssl x509 -req -days 3650 -sha1 -CA certs/ca.crt -CAkey private/ca.key -CAserial serial -CAcreateserial -in srx-j24-id.req -out certs/srx-j24.crt -extfile ext.cfg

c) Copy certs/srx-j24.crt and certs/ca.crt to the SRX box via scp to your srx user’s folder.

5) Load the certificate

a) Load local certificate

root@J24> request security pki local-certificate load certificate-id srx-j24-id filename srx-j24.crt 
Local certificate loaded successfully

b) Load CA certificate

root@J24> request security pki ca-certificate load ca-profile srx-ca filename ca.crt    
Fingerprint:
  d6:df:54:23:4d:50:7c:3d:fa:bc:ca:09:f6:44:9b:4a:bc:d3:c9:4b (sha1)
  b1:4f:87:82:bc:27:e8:a4:12:9a:59:1f:c8:2a:3f:36 (md5)
Do you want to load this CA certificate ? [yes,no] (no) yes 

CA certificate for profile srx-ca loaded successfully

So far we have finished the SPOKE side of the certificate loading. Very same operations
must be done for the HUB as well but on this time we will use IP address as the IKE-ID.
Here are two differences;

Note: If you want to use hostname as IKE-ID, you need to use the local-identity in the configuration. (See the comments for a discussion)

1) Certificate request creation

J41>request security pki generate-certificate-request certificate-id srx-j41-id subject "CN=Mr. Admin,OU=SRX Dept,C=NL" ip-address 212.45.65.2 filename srx-j41-req

Notice: instead of domain-name we specify IP of J41 device

2) ext.cfg file for certificate should be like below instead of hostname

subjectAltName=IP:212.45.65.2

6) Configure IPSEC/VPN
The only difference in configuration is phase1 (IKE). IPSEC config is the same as usual.
That is why I don’t even write them here.

J24 IKE

[edit]
root@J24# show security ike 
proposal prop-basic {
    authentication-method rsa-signatures;
    dh-group group2;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 3600;
}
policy pol-cert {
    mode main;
    proposals prop-basic;
    certificate {
        local-certificate srx-j24-id;
    }
}
gateway gw-j41-hub {
    ike-policy pol-cert;
    address 212.45.65.2;
    local-identity hostname j24.example.com;
    external-interface ge-0/0/0.0;
}

J41 (HUB)

[edit security]
root@J41-Amsterdam# show ike 
proposal prop-cert {
    authentication-method rsa-signatures;
    dh-group group2;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 3600;
}

policy pol-cert {
    mode main;
    proposals prop-cert;
    certificate {
        local-certificate srx-j41-id;
    }
}

gateway gw-j24 {
    ike-policy pol-cert;                
    dynamic hostname j24.example.com;
    external-interface ge-0/0/0.65;
}

7) Verification

root@J24> show security ike sa detail 
IKE peer 212.45.65.2, Index 1757680, Gateway Name: gw-j41-hub
  Role: Initiator, State: UP
  Initiator cookie: 25471da9b36bc685, Responder cookie: eb9395af529b5419
  Exchange type: Main, Authentication method: RSA-signatures
  Local: 192.168.180.2:500, Remote: 212.45.65.2:500
  Lifetime: Expires in 3003 seconds
  Peer ike-id: 212.45.65.2
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96 
   Encryption            : 3des-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                 1641
   Output bytes  :                 1869
   Input  packets:                    4
   Output packets:                    5
  Flags: IKE SA is created 
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Initiator, Message ID: 0
    Local: 192.168.180.2:500, Remote: 212.45.65.2:500
    Local identity: j24.example.com
    Remote identity: 212.45.65.2
    Flags: IKE SA is created

As you can see authentication method is RSA-signatures.

root@J24> show security ipsec sa detail 
  ID: 131073 Virtual-system: root, VPN Name: gw-j41-hub-cert
  Local Gateway: 192.168.180.2, Remote Gateway: 212.45.65.2
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.0

  Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 
  Last Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 104d10aa, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2927 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2305 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: a08d3472, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2927 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2305 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: 3des-cbc
    Anti-replay service: counter-based enabled, Replay window size: 64

About: rtoodtoo

Genco has worked for more than 10 years as a Network/Support Engineer. He is also interested in Python, Linux, Security and SD-WAN, currently lives in the Netherlands and works as a Network Support Engineer at Tesla Inc. // JNCIE-SEC #223 / RHCE / PCNSE


12 thoughts on “Certificate based IPSEC VPN in SRX”

  1. This manual is awful.
    1. Why do i need a Linux host?
    2. Why do I have to create CSR and keys on SRX host and what should I do with them on linux host?

    1. Linux is an example, if you can use Windows CA as the host. You have to create CSR to get your certificate. Lastly, this isn’t a manual but it is a summary of how we
      can create Cert VPN on SRX. In order to understand this topic, you also need some background knowledge.

  2. I don’t see you have copied locally generated certificate in CA ? you manually did alternate name and signed it. will this work?

  3. I didn’t type the command but only mentioned scp to the device only. If you mean that. So you need to copy to the device.

  4. Wonderful article!!! I was planning to write a blog on certificate based VPN on SRX. But after reading your blog I left out the idea and decided to promote this blog!!!

  5. rtoodtoo,

    I have this up and running in our testlab and in production thanks to your page! But just one question: Does the Hub have to be IP based? Meaning, why can’t the spokes connect to the hub using a fqdn if the hub certificate is created that way? I know all the juniper docs say to use an IP, but doesn’t the rest of the world use fqdn’s?

    Rob.

    1. Hi Robert,
      As the document is two years old, I don’t recall exactly why I wrote that. There is a good document at https://kb.juniper.net/kb/documents/public/junos/jsrx/JSeries_SRXSeries_IPSecVPN_with_PKI_Certificates_Primer_v13.pdf but there seems to be an issue to download. If you can find it, it can help you better understand. I think during my tests FQDN didn’t work but for some reason I didn’t mention this. Shame on me:) It should be a lesson for me.

      Best Regards
      Genco.

    1. Thanks for the feedback Robert. I have put a note on the case referring to the discussion here too.

      Genco.

You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.