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#
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.
    – Ron Maupin
    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.
    – bdx
    Commented Dec 21, 2020 at 22:31

2 Answers 2

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

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.
    – bdx
    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
    – Mario Jost
    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.
    – Mario Jost
    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.
    – bdx
    Commented Apr 29, 2020 at 23:45
  • Have you tried to download the CRL manually onto the router? Are you working with VRF's?
    – Mario Jost
    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.

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.
    – bdx
    Commented Apr 29, 2020 at 3:08
  • That's a bummer, thought it might be worth trying.
    – Stuggi
    Commented Apr 29, 2020 at 5:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.