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;