9800 WLC CLI PIV Works but Web GUI Doesn't

[jawesterholm]

I have successfully enabled PIV authentication for CLI via ISE.  However, web does not work, gives me openresty error after entering my PIN.  Background - I am with DOI and obtained a certificate for the WLC from the DOI CA.  Our PIV cards are provided by ENTRUST.  I use the Entrust trust point for CLI. 

This allows me to use CLI PIV -

crypto pki trustpoint ENTRUST_MG_SVC_SSP_CA
enrollment terminal
authorization username alt-subjectname userprinciplename
revocation-check none

cyrpto pki authenticate ENTRUST_MG_SVC_SSP_CA

Insert Certificate HERE

ip ssh server certificate profile
user
trustpoint verify ENTRUST_MG_SVC_SSP_CA

Ip http secure-trustpoint (WLC trustpoint)
Ip http secure-client-auth
ip http secure-peer-verify-trustpoint (WLC Trustpoint) - I've tried using ENTRUST_MG_SVC_SSP_CA as well.
ip http secure-piv-based-auth secure-piv-based-author-only

TAC has been working on this for a few months with no resolution yet.  Any suggestions?  I've tried 17.3, 17.4, 17.12.1, 17.12.2 with no changes.

[jawesterholm]

Yeah login isn't making it to ISE for me either.  I've debugged ip http, aaa authen, show logging process nginx internal start last 60, etc.  It seems to be some kind of ngnix error.  I also got DOI to give me a soft token to see if that made a difference vs my PIV card.  No change.

[jawesterholm]

Currently running 17.12.3

[edmonroy]

Try this:

For the trustpoint having the  Root CA of the client cert add the following:
crypto pki trustpoint PIV-Root-CA
    authorization username subjectname commonname

Then make sure that trustpoint is the one for PIV verification:

ip http secure-peer-verify-trustpoint PIV-Root-CA

[jawesterholm]

Sadly same OpenResty error

[JUANNN]

Hello everyone, 

If it helps to anyone, I achieved login in with my CAC card to the WebUi of a Cisco ISR 1000 router. Here are my configs:

I used a CentOS server as a CA and SUB CA server to sign both the client and router CSRs, with OpenSSL. Then, I imported the certificate to the trustpoint via the terminal. Cisco has good documentation on how to do this.

As far as my knolwedge goes, and please correct me if wrong:

- The command ip http secure-trustpoint ESCOBARS-ROOMLAB-SUB-CA-1 tells the router to do 2 things: to use the CA Certificate of this trustpoint to validate the ID certificate sent by the client, and to send the ID certificate of the router imported to this trustpoint to the client, to complete the TLS handshake.

- The command ip http secure-client-auth tells the router to request an ID certificate from the client.

The TLS handshake is completed...now the WebUI authentication starts:

- The command ip http secure-piv-based-auth secure-piv-based-author-only is CRUCIAL: it tells the router to use the ID certificate sent by the client for the WebUI authentication (this is, once the TLS handshake is completed, the Cisco router requires the user credentials for authentication again... not sure if is for an extra security step, maybe). 

- The command ip http secure-peer-verify-trustpoint ESCOBARS-ROOMLAB-SUB-CA-1 was my solution for the OpenResty error: apparently, it tells the router to "re-validate" the ID certificate sent by the client against the trustpoint specified, but this time for the WebUI login (last time with the ip http secure-trustpoint command it was for the TLS handshake). This is, the HTTPS peer (the client is already a peer since the TLS handshake has been completed) is attempting to use the same certificate for WebUI access and the router verifies it again? Please correct if wrong).

And now just verify the work:

I entered my PIN to sign the certificate...

Here the router already established the TLS handshake, and it already authenticated us too for the WebUI since we used the same  certificate for both things, so the browser asks us to accept the redirection to the WebUI... click OK and...

Now I can see that the CN of my certificate was used as my username automatically (I did not specify authorization username subjectname commoname under the trustpoint).

Here is a debug:

I know this is not ISE or WLC 9800, but I saw that the configs and commands were that you guy were talking about are the same I was using, so I hope it can hel someone. 

Thanks!

Juan

[kellymur]

One of my projects had the same goals in mind, using PIV-based authentication on Cisco C9800 Web GUI to provide 2FA.  All of the configurations are fairly straightforward.  Public documentation for the "ip http secure-peer-verify-trustpoint", "ip http secure-client-auth", and the association of CAs is not very helpful.  Like what you showed in your well-written example, we found the following items to be what got us past the OpenResty issues everyone has:

ip http secure-trustpoint <SEC_TRUSTPOINT>

Where <SEC_TRUSTPOINT> is the configured trustpoint that is used to issue the network device's host certificate.  In government terms, the Non-Person Entity (NPE) certificate.

ip http secure-peer-verify-trustpoint <SEC_PEER_TRUSTPOINT>

Where <SEC_PEER_TRUSTPOINT> is the authoritative trustpoint (either root or subordinate) that issued the end-user PIV certificate.

So, for example, if the WLC (or in your example, the CSR1000V) was issued a cert from RootCA1 and the user client Smart Card certificate was issued from SubCA 2 under RootCA2, the configuration might look something like the following:

ip http secure-trustpoint RootCA1

ip http secure-peer-verify-trustpoint RootCA2

Both RootCA1 and RootCA2 would require their trustpoint(s) to be authenticated and installed with the respective CA certificates on the CSR1000V or WLC.

If you're in the federal space and need to use UPN for your certificate SubjectName, you would go to the RootCA2 trustpoint (in this example) and configure it with "authorization username subjectname userprincipalname".  The UPN is commonly used and aligns with the information often carried in Directory Services for matching Smart Cards to ADUC user objects.

I've seen a slightly different configuration in the "ip http secure-peer-verify-trustpoint" where admins define the NPE issuing CA and then use the trustpoint to configure "chain-validation continue <SEC_PEER_TRUSTPOINT>".  I haven't personally tried that, but that logic may provide an alternative working configuration.

ip http secure-trustpoint RootCA1

ip http secure-peer-verify-trustpoint RootCA1

crypto pki trustpoint RootCA1

 chain-validation continue RootCA2

In either configuration example, the workflow is to use the NPE cert for the web GUI and point to the end-user client certificate CA chain to authenticate the client.  The problem that I see, in both configurations, is that you can only configure one "secure-peer-verify-trustpoint" value and one "chain-validation continue <SEC_PEER_TRUSTPOINT> value in each section.  So, by all indications, only one RootCA or SubCA can be specified and all client certificates must fall in that chain or they won't be validated.  If there is every a transitory time when client certificates come from two different RootCA chains, only one chain can be configured, so it appears to be an either/or problem on which client certificates are trusted or not.