3

On a Cisco 867 running IOS 15.6(3)M7, I'm trying to do the following:

TEST-GW1(config)#crypto pki trustpoint vpn-p2s-server-11 TEST-GW1(ca-trustpoint)#crl query http://myvpn/crls/21.crl % URL must begin with ldap://

I've found this post: https://community.cisco.com/t5/other-security-subjects/crl-request-via-ldap-on-c2611/td-p/214237 which seems to describe the same problem and suggests that there might be a flag or field I need to set differently in the trustpoint certificate, but I can't work out what it is I'd need to change there to allow an HTTP CRL endpoint for the trustpoint.

Additionally, I've found this: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/a1/sec-a1-xe-3se-3850-cr-book/sec-a1-xe-3se-3850-cr-book_chapter_0100.pdf which at the top of page 5 shows an example using the same commands that I've used in my example above where an HTTP CRL endpoint works.

The trustpoint certificate that was imported includes an HTTP CRL endpoint already and as far as I can tell, no mention of LDAP.

What do I have to do to allow the HTTP CRL lookup to be used on that trustpoint?

Edit:

The certificate I'm importing does have an HTTP CRL Distribution point in it already, but doesn't show up in the CRLs list:

HOST#show crypto pki certificates Certificate Status: Available Certificate Serial Number (hex): 00EA9801 Certificate Usage: General Purpose Issuer: cn=Test Intermediate CA o=MyVPN c=NZ Subject: Name: test.vpn.local cn=test.vpn.local o=MyVPN c=NZ CRL Distribution Points: http://myvpn/crls/21.crl Validity Date: start date: 13:22:25 NZST Apr 23 2020 end date: 13:22:25 NZST Apr 23 2023 Associated Trustpoints: vpn-p2s-server-11 Storage: nvram:myvpntest#8B45.cer HOST#show crypto pki crls HOST#
Improve this question
2
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. Commented Dec 17, 2020 at 17:08
  • I don't believe this issue was ever solved. The site we were trying this for is now using a Cisco ISR 1111 and it's working fine on that. Commented Dec 21, 2020 at 22:31

2 Answers 2

Reset to default
1
+50

Not sure if I can help you with the command directly, but i can show you another way of checking CRLs within a trustpoint. See following configuration:

Router(config)#crypto pki trustpoint INTERNALCA Router(ca-trustpoint)#vrf LAN Router(ca-trustpoint)#fqdn router.company.local Router(ca-trustpoint)#subject-name CN=router.company.local,O=COMPANY,OU=BRANCH,ST=AT,L=HUSTON,C=US Router(ca-trustpoint)#rsakeypair roRZ101 Router(ca-trustpoint)#revocation-check crl <------------ important command Router(ca-trustpoint)#enrollment terminal pem Router(ca-trustpoint)#fingerprint 3fff1121ac19736fcbaeb6f0244d34d64ee4cb3b Router(ca-trustpoint)#exit

If you then, import a certificate into the router based on this trustpoint, you need to have the CRL URLs within the certificate. In a windows environment, you would usually have 2 URLs. One LDAP which is used for internal windows clients and a HTTP which can be used for other clients internally or externally. You would then need to make sure this CRL is frequently uploaded from your CA to the Server where it would be reachable via the URL. If you check the certifiate on the router, you can see the embedded CRL URLs:

Router#show crypto pki certificates INTERNALCA Certificate Status: Available Certificate Serial Number (hex): 110000001D082B67CDE01F7B4100000000001D Certificate Usage: General Purpose Issuer: cn=COMPANY Root Certificate Authority ou=IT o=COMPANY c=US Subject: Name: router.company.local cn=router.company.local ou=BRANCH o=COMPANY l=HUSTON st=AT c=US CRL Distribution Points: http://ca.company.com/Root%20Certificate%20Authority.crl ldap:///CN=Root%20Certificate%20Authority,CN=SERVER02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=company,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint Validity Date: start date: 11:33:08 CET Mar 23 2018 end date: 11:33:08 CET Mar 20 2028 Associated Trustpoints: INTERNALCA Storage: nvram:COMPANYROOTCe#1D.cer

If you create a VPN connection or use the trustpoint otherwise, you can check the cached CRL on the router with following command:

Router#show crypto pki crls CRL Issuer Name: cn=Root Certificate Authority,ou=IT,o=COMPANY,c=US LastUpdate: 08:41:50 CEST Apr 16 2020 NextUpdate: 21:01:50 CEST Apr 19 2020 CRL downloaded at: 09:00:48 CEST Apr 16 2020 Retrieved from CRL Distribution Point: http://ca.company.com/Root%20Certificate%20Authority.crl CRL DER is 1946 bytes CRL is stored in parsed CRL cache Parsed CRL cache current size is 1946 bytes Parsed CRL cache maximum size is 65536 bytes

As usually only the HTTP URLs is reachable from outside the network, there will be an error while establishing a VPN connection for example:

*Apr 9 09:20:27.100: %PKI-4-CRL_LDAP_QUERY: An attempt to retrieve the CRL from ldap:///CN=Root%20Certificate%20Authority,CN=SERVER02,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=company,DC=local?certificateRevocationList?base?objectClass=cRLDistributionPoint using LDAP has failed

This error can be ignored, as the CRL via HTTP can be downloaded without issues and the VPN connection will be established. So i dont provide a direct solution, but i recommend that you integrate the CRL URL within the certificate itself.

If you create the cerfiticate on a Windows CA, the CRL field looks like following:

enter image description here

Improve this answer
7
  • Thanks for the detailed response. I've updated my question with more details - the certificate I'm importing already has the CRL Distribution Point set to an HTTP endpoint and the show crypto pki certificates command shows that it recognises that, however the show crypto pki crls command returns blank output. These certificates are generated by OpenSSL not Windows, and we don't have an LDAP server available as a CRL distribution point so I'm forced to only do it via HTTP. The revocation-check crl command you've listed is also already in my trustpoint config. Commented Apr 29, 2020 at 3:10
  • The show crypto pki crls does only work, once the trustpoint has been used. So the device needs to try to establish a VPN connection with this trustpoint relatet in order to trigger the download. So im guessing the router hasnt tried to download the CRL yet. If the router tried and did not succeed, you would see an error in the log. You simulate the download by simply issueing a copy command like copy http://myvpn/crls/21.crl flash:21.crl and then view the content by more flash:21.crl Commented Apr 29, 2020 at 14:10
  • Something else you can try is to use revocation-check none in your trustpoint just to test if the VPN connection is coming up without checking all the CRL stuff. Taking things step-by-step. Commented Apr 29, 2020 at 14:14
  • Good to know it needs to retrieve it first. I've set the trustpoint to use revocation-check crl none so it will check CRL first and then permit connection if not available. The VPN connection comes up successfully when doing that, but show crypto pki crls remains empty and watching the logs on the webserver hosting the CRL shows that no requests for the CRL were made. I've confirmed I can retrieve the CRL from the URL copied from the show crypto pki certificates command in my browser. Commented Apr 29, 2020 at 23:45
  • Have you tried to download the CRL manually onto the router? Are you working with VRF's? Commented Apr 30, 2020 at 16:25
0

My somewhat educated guess is that Cisco has added options to that command in later releases, and since IOS 15.4(3)M is rather old (2014), I'd guess that the http:// option was added later.

My recommendation is therefore to update to the latest version of the next branch, until your command starts working again.

Improve this answer
2
  • Thanks for the suggestion. I've brought that forward to 15.6(3)M7 which is the latest I can use per internal procedures, released Sep 2019, but still no command available. The Cisco forum post linked above was also from 2004, so I'd expect if it was going to be added since then it should have been already. Commented Apr 29, 2020 at 3:08
  • That's a bummer, thought it might be worth trying. Commented Apr 29, 2020 at 5:48

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.