cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
287
Views
3
Helpful
3
Replies

SSH with X509v3 certificates

JUANNN
Spotlight
Spotlight

Hello,

I am doing a little lab using SSHv2 with X509v3 certificate client authentication. I have a simple setup:

* Windows PC with 2 SSH clients:

- Putty with PuttyCAC for smartcard support

- PragmaFortress SSH Client with smartcard support

*C1121X-8PLTEPW running Cisco IOS XE Software, Version 17.12.05a

I have a smart card that contains the ID certificate that I wish to use for authentication. Following the document:

Configuring SSH with x509 authentication on IOS devices - Cisco

and also the PragmaSystems Guide for integration with Cisco devices using smartcard authentication.

But I cannot get it to work. I have been many days trying to figure out what I am doing wrong without success. Here are my configs on the router:

JUANNN_4-1749665454511.png

and I successfully installed the ROOT-CA certificate and the SUB-CA certificate on it as well (i was assuming that the sub-CA CA certificate was necessary, please correct me if this is wrong):

ROOT-CA

JUANNN_2-1749665168701.png

 

SUB-CA

JUANNN_1-1749665011284.png

From my understanding (and please correct me if wrong) these certificates are used to validate the signature of the ID certificate that is contained on my smartcard, since the issuing CA of my smartcard certificate is CA65 (the subCA):

JUANNN_3-1749665410890.png

Then, I use PragmaFortressClient or PuttyCAC to use my smartcard for authentication over SSH:

JUANNN_5-1749665812330.png

and I get the following:

JUANNN_6-1749665940094.png

JUANNN_7-1749665994080.png

I do not see anywhere the router receiving the certificate from the PragmaClient, or verifying it against the CA trustpoints. The thing is that the SSH client seems to be reading my smartcard because it uses as the username the Common Name field of the ID Certificate of the smartcard:

JUANNN_8-1749666261698.png

Any help is truly appreciated, thanks. I have been many days and hours stuck with this.

Juan

 

 

2 Accepted Solutions

Accepted Solutions

JUANNN
Spotlight
Spotlight

Hello everyone,

I just figured out! 

I had 2 things wrong:

- I had Pageant running at the same time I was trying to use PragmaFortressClient. This was caussing the issue that the SSH client from Pragma could not send the ID certificate of my smartcard, I am assuming because Pageant was the one using it? 

- The second issue was that I had to specify the command: authorization username subjectname commonname under the SUB-CA trustpoint. The missing of this command was causing the issue of not being able for the router to generate a username from the certificate received. According to Cisco documentation:

JUANNN_0-1749669539390.png

so since I was using aaa new-model, then this is required!! Note that no local usernames are required to be configured. Everything is retrieved from the ID certificate of the smartcard.

JUANNN_1-1749670035623.png

Finally, for anyone's interest, I can confirm that only the SUB-CA trustpoint is needed under the verification of the SSH Server (the ROOT-CA certificate is NOT needed to be installed in the router because the SUB-CA is already authenticated!!). And the chain-validation command is not needed neither way (I used to use this command for routers enrolling to SUB-CAs for IPsec VPN authentication with certificates, but here since there is no enrollment from the router part, there is no point in having it). The final configuration looks like:

JUANNN_2-1749670783836.png

JUANNN_3-1749670851312.png

As long as we authenticate the SUB-CA via the terminal (or dynamically if the case), SSH authentication with certificates works good!

I hope this helps anyone trying to implement this, regards

Juan

 

 

View solution in original post

Arne Bier
VIP
VIP

This is a great bit of a lab work and I am certain someone will find this useful. I was wondering about the use of the Sub-CA versus the Root CA. What happens when the sub-CA expires? Then you have to renew all the trustpoints on all your devices. Would it not have been better to install the longer-lived (usually) Root CA to make the solution future proof?

View solution in original post

3 Replies 3

JUANNN
Spotlight
Spotlight

Hello everyone,

I just figured out! 

I had 2 things wrong:

- I had Pageant running at the same time I was trying to use PragmaFortressClient. This was caussing the issue that the SSH client from Pragma could not send the ID certificate of my smartcard, I am assuming because Pageant was the one using it? 

- The second issue was that I had to specify the command: authorization username subjectname commonname under the SUB-CA trustpoint. The missing of this command was causing the issue of not being able for the router to generate a username from the certificate received. According to Cisco documentation:

JUANNN_0-1749669539390.png

so since I was using aaa new-model, then this is required!! Note that no local usernames are required to be configured. Everything is retrieved from the ID certificate of the smartcard.

JUANNN_1-1749670035623.png

Finally, for anyone's interest, I can confirm that only the SUB-CA trustpoint is needed under the verification of the SSH Server (the ROOT-CA certificate is NOT needed to be installed in the router because the SUB-CA is already authenticated!!). And the chain-validation command is not needed neither way (I used to use this command for routers enrolling to SUB-CAs for IPsec VPN authentication with certificates, but here since there is no enrollment from the router part, there is no point in having it). The final configuration looks like:

JUANNN_2-1749670783836.png

JUANNN_3-1749670851312.png

As long as we authenticate the SUB-CA via the terminal (or dynamically if the case), SSH authentication with certificates works good!

I hope this helps anyone trying to implement this, regards

Juan

 

 

Arne Bier
VIP
VIP

This is a great bit of a lab work and I am certain someone will find this useful. I was wondering about the use of the Sub-CA versus the Root CA. What happens when the sub-CA expires? Then you have to renew all the trustpoints on all your devices. Would it not have been better to install the longer-lived (usually) Root CA to make the solution future proof?

Hello @Arne Bier , 

Thanks for you interest and answer. You definitely stated the best solution, thanks so much. Now I removed the SUBCA trustpoints, I specified to verify the Root Ca one on the ip ssh certificate profile… and it works for any smartcard of our organization, without having to add SubCa certificates for groups of users. 

Thanks,

Juan

Review Cisco Networking for a $25 gift card