01-24-2011 04:36 AM
Hi!
Now I am testing site-to-site VPN between two IOS 12.4 routers (2821 and 881) with IKE authorization by RSA-SIG.
Both routers successfully received certificates from the same CA.
Trustpoint configurations on both routers were also the same:
!
crypto pki trustpoint demo_CS
enrollment url http://10.10.0.100:80
serial-number
revocation-check crl none
!
After I sent traffic from a test user of 2821 router to 881 router the certificate exchange was successfull and the tunnel established correctly. Ping was successfull.
Then I decided to include RADIUS authentication for certificate credentials received from the peer.
I added the following on both routers:
!
aaa authorization network cert group radius
!
crypto pki trustpoint demo_CS
enrollment url http://10.10.0.100:80
serial-number
revocation-check crl none
authorization list cert
authorization username subjectname commonname
!
radius-server host 172.20.120.154 auth-port 1645 acct-port 1646
radius-server key cisco
!
The ACS interacts with both peers by RADIUS properly. Terminal users of the routers are authenticated on it.
I cleared the old isakmp session (rebooted 881) and turned on debugs on both routers.
Cisco-881#show debugging
General OS:
AAA Authentication debugging is on
AAA Authorization debugging is on
Radius protocol debugging is on
Radius packet protocol debugging is on
PKI:
Crypto PKI Msg debugging is on
Crypto PKI Trans debugging is on
Then I repeated the test. I sent ICMP echo from 2821 to 881. The ping was not successull and I received the following debug messages on 881.
Jan 24 12:16:49.734: CRYPTO_PKI: Trust-Point demo_CS picked up
Jan 24 12:16:49.734: CRYPTO_PKI: unlocked trustpoint demo_CS, refcount is 1
Jan 24 12:16:49.734: CRYPTO_PKI: locked trustpoint demo_CS, refcount is 2
Jan 24 12:16:49.786: CRYPTO_PKI: Added x509 peer certificate - (677) bytes
Jan 24 12:16:49.786: CRYPTO_PKI: validation path has 1 certs
Jan 24 12:16:49.786: CRYPTO_PKI: Found a issuer match
Jan 24 12:16:49.786: CRYPTO_PKI: Using demo_CS to validate certificate
Jan 24 12:16:49.794: CRYPTO_PKI: Starting CRL revocation
Jan 24 12:16:49.806: CRYPTO_PKI: Certificate validated
Jan 24 12:16:49.806: CRYPTO_PKI: Anticipate checking AAA list: 'cert'
Jan 24 12:16:49.806: CRYPTO-PKI: Cert has the following key-usage flags: Digital-Signature, Key-Encipherment
Jan 24 12:16:49.806: %PKI-3-CERTIFICATE_INVALID_UNAUTHORIZED: Certificate chain validation has failed. Unauthorized
Jan 24 12:16:49.806: CRYPTO_PKI: chain cert was anchored to trustpoint demo_CS, and chain validation result was: CRYPTO_PKI_CERT_NOT_AUTHORIZED
Jan 24 12:16:49.806: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 10.10.0.1 is bad: certificate invalid
Jan 24 12:16:54.178: CRYPTO_PKI: unlocked trustpoint demo_CS, refcount is 1
There are only crypto PKI debug messages. Neither RADIUS nor AAA messages.
Debug messages on 2821 did not appear at all.
Please, help me find what I missed in the configuration.
01-25-2011 11:09 AM
Viktor,
I guess you're studying for your CCIE now? I've been working with IOS VPN for several years and I only saw this during CCIE ;-)
My suggestion - simplify and if it does not kick off try with tacacs instead of radius.
For example I don't believe that strictly speaking you need to set both subject name and CN as username ;-)
Example with tacacs:
Right now I'm too lazy to check this, but I could dig into and find my lab setup.
Marcin
01-26-2011 12:02 AM
Yes, Marcin. Now I am learning CCIE Security program.
Debugging this I found one interesting thing. i also turned on 'crypto isakmp' debugging on 2821 and noticed that certificate received from the peer is considered the following way:
next-payload : 6
type : 9
Dist. name : serialNumber=FCZ123012YN+hostname=Cisco-881
protocol : 17
port : 500
length : 56
I configured authorization on the trustpoint as 'authorization username subjectname commonname'. I expected the router to send Radius Access-Request packet with 'Cisco-881' as username. But the router can not distinguish the CN parameter from the received certificate. So it does not send anything to Radius and reports that authorization fails. When I changed 'authorization username subjectname commonname' to 'authorization username subjectname all' the router sent Radius Access-Request with 'serialNumber=FCZ123012YN+hostname=Cisco-881' as username.
Then I used the same trustpoint for IKE authentication for Cisco VPN Client. In 'crypto isakmp' debugging result a saw the following about the certificate received from the client.
next-payload : 6
type : 9
Dist. name : cn=vpntunnel,ou=vpngroup
protocol : 17
port : 500
length : 50
After that Radius Access-Request message was sent with correct username = 'vpntunnel'.
My conclusion is that IOS router receives certificate credentials from another IOS router incorrectly. Its string does not distinguish attributes. I do not know the reason why it happens. At the same time a similar certificate from a VPN Client is received with attributes distinguished one from another.
Is it a bug?
01-26-2011 04:25 AM
Viktor,
Good find!
Wellllllllllllllll it doesn not look like a bug. The certificate should at least contain CN (common name) and typically a OU - exactly like you have on VPN client. . In your case it looks like CN CSR you generated did not contain any of those fileds and you have on the 8xx router configured to include hostname and serial.
Can you re-enroll the router setting subject-name manually under trustpoint to cn=HOST.DOMAIN,ou=vpngroup ?
Marcin
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide