Using Digital Certificates to Create Dynamic IPSec SAs

Problem

You want an outside certificate authority (CA) to provide a digital certificate that sets the shared keys instead of using internal preshared keys.

Solution

Before you can configure IPSec, you must request a digital certificate from a trusted CA and put a copy of it on your router. First, configure a CA profile:

	[edit security]
	aviva@RouterA# set pki ca-profile entrust ca-identity entrust
	aviva@RouterA# set pki ca-profile entrust enrollment url 
http://server.ca.com/cgi-bin/pkiclient.exe
	aviva@RouterA# commit and-quit

Then, use the CA profile to request a CA certificate from the CA and load it onto the router:

	aviva@RouterA> request security pki ca-certificate enroll ca-profile entrust
	Received following certificates:
	 Certificate: C=us, O=mycompany
	 Fingerprint: 00:8e:6f:58:dd:68:bf:25:0a:e3:f9:17:70:d6:61:f3:53:a7:79:10
	 Certificate: C=us, O=mycompany, CN=First Officer
	 Fingerprint: bc:78:87:9b:a7:91:13:20:71:db:ac:b5:56:71:42:ad:1a:b6:46:17
	 Certificate: C=us, O=mycompany, CN=First Officer
	 Fingerprint: 46:71:15:34:f0:a6:41:76:65:81:33:4f:68:47:c4:df:78:b8:e3:3f
	Do you want to load the above CA certificate ? [yes,no] (no) yes

Next, generate a public/private key pair, which is required to submit a request for a local certificate:

	aviva@RouterA> request security pki generate-key-pair certificate-id local-entrust
	Generated key pair local-entrust, key size 1024 bits

Then, send a request for a local certificate to the CA:

	aviva@RouterA> request security pki generate-certificate-request certificate-id
	local-entrust domain-name RouterA.mycompany.com filename entrust-request-RouterA
	subject cn=RouterA.mycompany.com
	Generated 
certificate request
	-----BEGIN CERTIFICATE REQUEST-----
	MIIBoTCCAQoCAQAwGjEYMBYGA1UEAxMPdHAxLmp1bmlwZXIubmV0MIGfMA0GCSqG
	SIb3DQEBAQUAA4GNADCBiQKBgQCiUFklQws1Ud+AqN5DDxRs2kVyKEhh9qoVFnz+
	Hz4c9vsy3B8ElwTJlkmIt2cB3yifB6zePd+6WYpf57Crwre7YqPkiXM31F6z3YjX
	H+1BPNbCxNWYvyrnSyVYDbFj8o0Xyqog8ACDfVL2JBWrPNBYy7imq/K9soDBbAs6
	5hZqqwIDAQABoEcwRQYJKoZIhvcNAQkOMTgwNjAOBgNVHQ8BAf8EBAMCB4AwJAYD
	VR0RAQH/BBowGIIWdHAxLmVuZ2xhYi5qdW5pcGVyLm5ldDANBgkqhkiG9w0BAQQF
	AAOBgQBc2rq1v5SOQXH7LCb/FdqAL8ZM6GoaN5d6cGwq4bB6a7UQFgtoH406gQ3G
	3iH0Zfz4xMIBpJYuGd1dkqgvcDoH3AgTsLkfn7Wi3x5H2qeQVs9bvL4P5nvEZLND
	EIMUHwteolZCiZ70fO9Fer9cXWHSQs1UtXtgPqQJy2xIeImLgw==
	-----END CERTIFICATE REQUEST-----
	Fingerprint:
	0d:90:b8:d2:56:74:fc:84:59:62:b9:78:71:9c:e4:9c:54:ba:16:97 (sha1)
	1b:08:d4:f7:90:f1:c4:39:08:c9:de:76:00:86:62:b8 (md5)

After the CA digitally signs the local certificate and returns it to you, copy it to the router and load it:

	aviva@RouterA> request security pki local-certificate load filename /tmp/RouterA-cert 
certificate-id local-entrust
	Local certificate local-entrust loaded successfully

Repeat this procedure to obtain and configure the digital certificate on the remote IPSec peer router.

Now you can configure IKE and IPSec to use the digital certificate. First, configure IKE to use the digital certificate for authentication:

	[edit 
services ipsec-vpn]
	aviva@RouterA# set ike proposal  ike-proposal  authentication-method rsa-signatures 

Create an IKE policy:

	[edit services ipsec-vpn ike policy digital-cert-policy ]
	aviva@RouterA# set proposals ike-proposal 
	aviva@RouterA# set local-id fqdn RouterA.mycompany.com 
	aviva@RouterA# set remote-id fqdn RouterB.mycompany.com 
	aviva@RouterA# set local-certificate local-entrust 

Then, create a rule for a bidirectional dynamic IKE SA that references the IKE policy:

	[edit services ipsec-vpn rule digital-cert-rule ]
	aviva@RouterA# set term ike then remote-gateway 10.0.15.2 
	aviva@RouterA# set term ike then dynamic ike-policy digital-cert-policy 
	aviva@RouterA# set match-direction input 

Define a service set for IPSec:

	[edit services service-set digital-cert-service ]
	aviva@RouterA# set ipsec-vpn-rules digital-cert-rule 
	aviva@RouterA# set ipsec-vpn-options local-gateway 10.1.15.1 
	aviva@RouterA# set ipsec-vpn-options trusted-ca entrust 
	aviva@RouterA# set next-hop-service inside-service-interface sp-1/2/0.1 
	aviva@RouterA# set next-hop-service outside-service-interface sp-1/2/0.2 

Then, configure the IPSec tunnel to be established immediately:

	[edit services ipsec-vpn]
	aviva@RouterA# establish-tunnels immediately

Next, configure the router interfaces. First, set up the service interfaces to use for IPSec:

	[edit interfaces]
	aviva@RouterA# set sp-1/2/0 unit 0 family inet
	aviva@RouterA# set sp-1/2/0 unit 1 family inet
	aviva@RouterA# set sp-1/2/0 unit 1 service-domain inside
	aviva@RouterA# set sp-1/2/0 unit 2 family inet
	aviva@RouterA# set sp-1/2/0 unit 2 service-domain outside

Then, configure the physical interface to be used for the IPSec tunnel:

	[edit interfaces]
	aviva@RouterA# set so-0/0/1 unit 0 family inet address 10.1.15.1/30

Finally, configure the IGP traffic to use the IPSec tunnel:

	[edit protocols ospf area 0.0.0.0 ]
	aviva@RouterA# set interface so-0/0/0 
	aviva@RouterA# set interface lo0.0 passive 
	aviva@RouterA# set interface sp-1/2/1 

Configure the other IPSec peers in a similar fashion.

Discussion

Digital certificates provide an additional level of security for connections between IPSec peers. They use a public-key infrastructure ( PKI) to provide public-key encryption and digital-signature services for managing keys and certificates. A trusted third party, called a certificate authority (CA), registers the identity of PKI users, storing the identities in a digital format called a public-key certificate, also called a CA certificate. The CA creates a CA certificate that includes your public key and its public key and signs it with its own private key. You then install the CA certificate, along with a local certificate that you generate, on your routers. When routers are setting up an IPSec tunnel between each other, each router receives a copy of its peer's local certificate, which has been signed by the CA's private key. The router uses the CA's public key to de-encrypt the local certificate and to learn its peer's public key, which it then uses to encrypt the data it sends. In networks that do not use digital certificates, IPSec encrypts data with the private key and its peers de-encrypt the data with the public key. This recipe works only on routers running JUNOS 7.5 and later.

Before you can configure IPSec to use digital certificates, you must request a certificate from the CA. The first commands in this recipe show how to make the request from the router. First, you configure a CA profile. This recipe creates a profile named entrust for the CA Entrust. The second command provides the URL of the CA.

After you have committed the CA profile, use the request security pki ca-certificate enroll command to request a certificate from the CA and load it onto the router. If you instead obtain the certificate from the CA in an email or by downloading it from its web site, use the following command instead to load the certificate onto the router:

	aviva@RouterA> request security pki ca-certificate load filename server1://tmp/
	RouterA-cert certificate-id entrust

To request a local certificate from the CA, you need to first generate a private-/ public-key pair with the request security pki generate-key-pair command. In the certificate-id option, specify the name you want to use for the local certificate (here, local-entrust). Once IPSec is operational, the public key will be included in the local digital certificate and the private key will be used to de-encrypt data received from peers.

The request security pki generate-certificate-request sends a request for a local certificate to the CA. When the CA returns the digitally signed local certificate, use the request security pki local-certificate load command to copy the certificate to the router. You can check the digital certificate with the following command:

	 aviva@RouterA> show security pki ca-certificate detail
	 Certificate identifier: entrust
	 Certificate version: 3
	 Serial number: 4355 9235
	 Issuer:
	 Organization: mycompany, Country: us
	 Subject:
	 Organization: mycompany, Country: us
	 Validity:
	 Not before: 2005 Oct 18th, 23:54:22 GMT
	 Not after: 2025 Oct 19th, 00:24:22 GMT
	 Public key algorithm: rsaEncryption(1024 bits)
	 cb:9e:2d:c0:70:f8:ea:3c:f2:b5:f0:02:48:87:dc:68:99:a3:57:4f
	 0e:b9:98:0b:95:47:0d:1f:97:7c:53:17:dd:1a:f8:da:e5:08:d1:1c
	 78:68:1f:2f:72:9f:a2:cf:81:e3:ce:c5:56:89:ce:f0:97:93:fa:36
	 19:3e:18:7d:8c:9d:21:fe:1f:c3:87:8d:b3:5d:f3:03:66:9d:16:a7
	 bf:18:3f:f0:7a:80:f0:62:50:43:83:4f:0e:d7:c6:42:48:c0:8a:b2
	 c7:46:30:38:df:9b:dc:bc:b5:08:7a:f3:cd:64:db:2b:71:67:fe:d8
	 04:47:08:07:de:17:23:13
	 Signature algorithm: sha1WithRSAEncryption
	 Fingerprint:
	 00:8e:6f:58:dd:68:bf:25:0a:e3:f9:17:70:d6:61:f3:53:a7:79:10 (sha1)
	 71:6f:6a:76:17:9b:d6:2a:e7:5a:72:97:82:6d:26:86 (md5)
	 Distribution CRL:
	 C=us, O=mycompany, CN=CRL1
	 http://CA-1/CRL/mycompany.crl
	 Use for key: CRL signing, Certificate signing

	Certificate identifier: entrust
	 Certificate version: 3
	 Serial number: 4355 925c
	 Issuer:
	 Organization: mycompany, Country: us
	 Subject:
	 Organization: mycompany, Country: us, Common name: First Officer
	 Validity:
	 Not before: 2005 Oct 18th, 23:55:59 GMT
	 Not after: 2008 Oct 19th, 00:25:59 GMT
	 Public key algorithm: rsaEncryption(1024 bits)
	 c0:a4:21:32:95:0a:cd:ec:12:03:d1:a2:89:71:8e:ce:4e:a6:f9:2f
	 1a:9a:13:8c:f6:a0:3d:c9:bd:9d:c2:a0:41:77:99:1b:1e:ed:5b:80
	 34:46:f8:5b:28:34:38:2e:91:7d:4e:ad:14:86:78:67:e7:02:1d:2e
	 19:11:b7:fa:0d:ba:64:20:e1:28:4e:3e:bb:6e:64:dc:cd:b1:b4:7a
	 
ca:8f:47:dd:40:69:c2:35:95:ce:b8:85:56:d7:0f:2d:04:4d:5d:d8
	 42:e1:4f:6b:bf:38:c0:45:1e:9e:f0:b4:7f:74:6f:e9:70:fd:4a:78
	 da:eb:10:27:bd:46:34:33
	 Signature algorithm: sha1WithRSAEncryption
	 Fingerprint:
	 bc:78:87:9b:a7:91:13:20:71:db:ac:b5:56:71:42:ad:1a:b6:46:17 (sha1)
	 23:79:40:c9:6d:a6:f0:ca:e0:13:30:d4:29:6f:86:79 (md5)
	 Distribution CRL:
	 C=us, O=mycompany, CN=CRL1
	 http://CA-1/CRL/mycompany.crl
	 Use for key: Key encipherment

	Certificate identifier: entrust
	 Certificate version: 3
	 Serial number: 4355 925b
	 Issuer:
	 Organization: mycompany, Country: us
	 Subject:
	 Organization: mycompany, Country: us, Common name: First Officer
	 Validity:
	 Not before: 2005 Oct 18th, 23:55:59 GMT
	 Not after: 2008 Oct 19th, 00:25:59 GMT
	 Public key algorithm: rsaEncryption(1024 bits)
	 ea:75:c4:f3:58:08:ea:65:5c:7e:b3:de:63:0a:cf:cf:ec:9a:82:e2
	 d7:e8:b9:2f:bd:4b:cd:86:2f:f1:dd:d8:a2:95:af:ab:51:a5:49:4e
	 00:10:c6:25:ff:b5:49:6a:99:64:74:69:e5:8c:23:5b:b4:70:62:8e
	 e4:f9:a2:28:d4:54:e2:0b:1f:50:a2:92:cf:6c:8f:ae:10:d4:69:3c
	 90:e2:1f:04:ea:ac:05:9b:3a:93:74:d0:59:24:e9:d2:9d:c2:ef:22
	 b9:32:c7:2c:29:4f:91:cb:5a:26:fe:1d:c0:36:dc:f4:9c:8b:f5:26
	 af:44:bf:53:aa:d4:5f:67
	 Signature algorithm: sha1WithRSAEncryption
	 Fingerprint:
	 46:71:15:34:f0:a6:41:76:65:81:33:4f:68:47:c4:df:78:b8:e3:3f (sha1)
	 ee:cc:c7:f4:5d:ac:65:33:0a:55:db:59:72:2c:dd:16 (md5)
	 Distribution CRL:
	 C=us, O=mycompany, CN=CRL1
	 http://CA-1/CRL/mycompany.crl
	 Use for key: 
Digital signature

The output shows three certificates. The first one is used to sign the certificate, the second is for encrypting the key, and the last is the CA's digital signature.

Use the following command to display information about the local certificate:

	aviva@RouterA> show security pki local-certificate
	Certificate identifier: local-entrust
	 Issued to: RouterA.mycompany.com, Issued by: mycompany
	 Validity:
	 Not before: 2005 Nov 21st, 23:28:22 GMT
	 Not after: 2008 Nov 21st, 23:58:22 GMT
	 Public key algorithm: rsaEncryption(1024 bits)
	 Public key verification status: Passed

The first line of the output shows the name of the certificatehere, local-entrust. The second line shows the router and company to whom the certificate has been issued. The certificate is valid for three years from the date of issue.

When you have the signed local certificate, configure IKE and IPSec to use it. The configuration is more involved than that shown in Recipe 3.3 because this recipe uses fewer of the default values.

In configuring IKE, the set ike proposal command has IKE use the digital certificate for authentication (with the option authentication-method rsa-signatures) instead of the default preshared keys. In the IKE policy, the set proposals command references the IKE proposal. The second and third commands give the fully qualified domain names of the local and remote routers that are the IPSec tunnel peers. The last command configures the name of the local router's digital certificate. Finally, define a rule for the IKE SA. This recipe creates a rule named digital-cert-rule. The first set term command defines the IP address of the remote end of the IPSec tunnel, and the second associates the IKE policy with the SA so that matching packets can be sent across the tunnel.

Next, configure IPSec. The service set is the same as that shown in Recipe 3.3, with the addition of the set ipsec-vpn-options trusted-ca command, which points to the CA you defined with the set security pki ca-profile command. Finally, use the set ipsec-vpn establish-tunnels immediately command to create the IPSec tunnel immediately after the configuration is activated rather than wait for traffic before setting it up.

In this recipe, the configuration for the services interface, the physical interface, and the IGP is the same as in Recipe 3.3. And again, configure the remote security router in the same way.

To check the operation of IKE and IPSec, use the commands shown in Recipe 3.3. Use the show services ipsec-vpn certificates command to check that the correct digital certificates are being used to establish the IPSec tunnel:

	aviva@RouterA> show services ipsec-vpn certificates
	Service set: ipsec-domain, Total entries: 3
	 Certificate cache entry: 3
	 Flags: Non-root Trusted
	 Issued to: RouterB.mycompany.com, Issued by: mycompany
	 Alternate subject: RouterB.mycompany.com
	 Validity:
	 Not before: 2005 Nov 21st, 23:33:58 GMT
	 Not after: 2008 Nov 22nd, 00:03:58 GMT

	 
Certificate cache entry: 2
	 Flags: Non-root Trusted
	 Issued to: RouterA.mycompany.com, Issued by: mycompany
	 Alternate subject: RouterA.mycompany.com
	 Validity:
	 Not before: 2005 Nov 21st, 23:28:22 GMT
	 Not after: 2008 Nov 21st, 23:58:22 GMT

	 Certificate cache entry: 1
	 Flags: Root Trusted
	 Issued to: mycompany, Issued by: mycompany
	 Validity:
	 Not before: 2005 Oct 18th, 23:54:22 GMT
	 Not after: 2025 Oct 19th, 00:24:22 GMT

The three certificates shown in this output map to the three you see with the show security pki ca-certificate detail command.

Again, this is a fairly complex configuration, so here are all the sections of the configuration in one place, with added comments:

	[edit security]
	pki { # <-- how to reach 
certificate authority
	 ca-profile entrust {
	 ca-identity entrust;
	 enrollment {
	 url http://server.ca.com/cgi-bin/pkiclient.exe;
	 }
	 }
	}

	[edit services]
	service-set 
digital-cert-service {
	 next-hop-service {
	 inside-service-interface sp-1/2/0.1; # <-- bind IPSec to sp-1/2/0.1
	interface
	 outside-service-interface sp-1/2/0.2; # <--bind IPSec to sp-1/2/0.2
	interface
	 }
	 ipsec-vpn-options {
	 trusted-ca entrust; # <-- bind service set to CA defined in ca-profile
	 local-gateway 10.1.15.1; # <-- local side of IPSec tunnel
	 }
	 ipsec-vpn-rules digital-cert-rule;
	}
	ipsec-vpn {
	 rule digital-cert-rule { # <-- policy to allow traffic into IPSec tunnel
	 term ike {
	 then {
	 remote-gateway 10.1.15.2; # <-- remote side of IPSec tunnel
	 dynamic {
	 ike-policy digital-cert-policy; # <-- bind IKE policy to IPSec
	 }
	 }
	 }
	 match-direction input;
	 }
	 ike {
	 proposal ike-proposal {
	 authentication-method rsa-signatures; # <-- use digital certificates
	 }
	 policy digital-cert-policy { #<-- define IKE policy
	 proposals ike-proposal;
	 local-id fqdn RouterA.mycompany.com;
	 local-certificate local-entrust;
	 remote-id fqdn RouberB.mycompany.com;
	 }
	 }
	 establish-tunnels immediately;
	}

	[edit interfaces]
	so-0/0/0 { #<-- physical interface for IPSec tunnel
	 unit 0 {'
	 family inet {
	 address 10.1.15.1/30;
	 }
	 }
	}
	sp-1/2/0 { # <-- services interface to IPSec
	 unit 0 {
	 family inet;
	 }
	 unit 1 { # <-- logical interface for IPSec inward-facing traffic
	 family inet;
	 service-domain inside;
	 }
	 unit 2 { # <-- logical interface for IPSec outward-facing traffic
	 family inet;
	 service-domain outside;
	 }
	}

	[edit protocols ospf area 0.0.0.0]
	interface so-0/0/0.0;
	interface sp-1/2/0.1; # <-- direct OSPF traffic into IPSec tunnel
	interface lo0.0;