On VMC when an AP is re-provisioned as RAP we need to specify the trust anchor as being the self-signed cert of the VMC.
There may be a requirement that self-signed certs are not permitted in customer environment or it is necessary to only use certs signed by an internal CA. Additionally, the Crypto properties of the self-signed cert on the VMC may not be suitable to the security team, being SHA1 and lifetime of 10 years.
Furthermore, when standalone VMC are used then the RAP cannot failover between the two since there is a different trust-anchor. The use of an MM deployment does make this easier since the trust-anchor becomes that of the MM self-signed cert and is common on all VMC that sit under that MM, however in some cases it may not be possible to deploy an MM, or for reasons such as above, it may be preferable to use a custom server-cert.
Provisioning a RAP itself use a custom-cert is possible, however this greatly increases the overhead and work during deployment.
Prior to 8.7 if a controller detected a RAP connection, it would always send either the factory cert or self-signed cert regardless of the configured trust-list that the RAP was requesting.
184.108.40.206 introduces the ability to be able to use a custom cert for VMC whilst still allowing the RAPs to use their own factory cert in a ‘hybrid certificate mode’.
- Obtain a server cert for the VMC signed by an internal CA and upload as server cert. This cert should also contain any signing/intermediate certs chained in the correct order.
- The root certificate that signed the server cert should also be uploaded to the VMC as a TrustedCA.
- Upload both certs to the VMC.
- Under Configuration --> Services --> VPN --> Certificates for VPN clients. Add the root cert uploaded before.
- In certificate Groups for VPN clients add new and choose the CA cert from above and the server cert to be that was uploaded before.
To further clarify this configuration, because it can be somewhat confusing. When the VPN client/RAP connects it will send the pubkey-hash of the trust-anchor (if present) in the Certificate-Request payload. If that trust-anchor/CAcert is present in the certificate-group then the controller will use the custom server cert defined in the certificate-group.
What it does NOT do is choose a server-cert based on the VPN clients own CA.
- We need to then reprovision the CAP as a RAP with this new custom trust-anchor. On the AP provisioning page, set the trust anchor to be that of the root cert uploaded before.
(VMC) [mynode] (config) #crypto-local isakmp certificate-group server-certificate <server-cert> ca-certificate <ca-cert>
(VMC1) [mm] #show crypto-local isakmp certificate-group
ISAKMP Certificate Groups
Server certificate name CA certificate name
Whilst not common, the following is the equivalent CLI commands to re-provision the AP as RAP.
read-bootinfo ap-name <ap-name>
copy-provisioning-params ap-name <ap-name>
reprovision ap-name <ap-name>
To verify the VPN connection of the RAP with VMC check the following.
(VMC1) [mynode] # show crypto isakmp sa peer 172.17.15.209
Initiator IP: 172.17.15.209
Responder IP: 172.20.10.111
Initiator cookie:7c06d5779d91a635 Responder cookie:a0fc6925314dd43d
SA Creation Date: Tue Aug 4 16:30:42 2020
Life secs: 28800
Initiator Phase1 ID: CN=CNK6KSM053::20:4c:03:b6:ac:ac
Responder Phase1 ID: C=GB S=England L=London O=LAB OU=nothing CN=VMC1.hpearubademo.com Efirstname.lastname@example.org
Exchange Type: IKE_SA (IKEV2)
Phase1 Transform:EncrAlg:AES256 HashAlg:HMAC_SHA2_256_128 DHGroup:14
Authentication Method: RSA Digital Signature 2048-bits
CFG Inner-IP 100.111.111.20
IPSEC SA Rekey Number: 0
With 'logging security process crypto level debug' enabled the following would be seen in the security logs.
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| 172.17.15.209:57045-> asn_cert_ike_subj_string Cert-len:1713 Subject: /CN=CNK6KSM053::20:4c:03:b6:ac:ac
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| 172.17.15.209:57045-> asn_cert_ike_serialNumber_string Cert-len:1713 Serial Number: 2C:FD:DC:99:00:00:00:7D:F1:44
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| 172.17.15.209:57045-> IKE_certGetKey : ARUBA cert MAC:20:4c:03:b6:ac:ac
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| 172.17.15.209:57045-> IKE_certGetKey : cert CN:20:4c:03:b6:ac:ac
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| 172.17.15.209:57045-> get the vlan 2010 from ip in pxSa
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| 172.17.15.209:57045-> IKE_certGetKey: Aruba AP cert validated successfully against device ca cert
Aug 4 16:30:42 :103082: <5788> <INFO> |ike| IKEv2 Client-Authentication succeeded for 100.111.111.20 (External 172.17.15.209) for default-vpn-role
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| IKE_useCert certchain:(nil)
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| ikev2_server_can_use_factory_cert:3557 trying self-signed cert
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| ikev2_server_can_use_factory_cert:3568 trying field ca cert: Aruba-Field-CA
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| IKE_CUSTOM_useCert group ca-cert: bits: rsa:2048 ec:0
Aug 4 16:30:42 :103063: <5788> <DBUG> |ike| IKE_CUSTOM_useCert: found valid Server-Cert:VMC1.chained