CRL checking problem.

[narcis antonie]

Hello,

I am facing the same problem as here: https://supportforums.cisco.com/thread/2047836.

The  main ideea is that I want to implement secure gre over ipsec with  digital certificates. The problem is that I want to do everything  off-line (with copy/paste), even the revocation checking (by using a crl  file copy/pasted form the CA on a microsoft IIS http server, because I  don't have the possibility to use a ldap server).

Everything goes  well untill I want to check the crl. At that point the routers are showing  "error #705h" after reading the crl file (I know that the file is read  because I can see the content of it if I do debug, the error is shown  afterwards).

If I issue the "show crypto pki crls" command, nothing is shown, so the routers are not loading the crl file.

The hierarchy is as follows: ROOT_CA --> 1st SUB_CA --> 2nd SUB_CA --> routers (the routers are not connected with the CAs, I am loading all certificates by hand with copy/paste).

Is it even possible to do everything off-line, or do I need at least the last SUB_CA to be on-line with the routers?

Thanks in advance,

Narcis Antonie

[narcis antonie]

No one?

Can, at least, someone tell me if what I am trying to do is posible?

Thanks in advance,

Narcis

[Marcin Latosiewicz]

Narcis,

Can you please post the CRL file here?

please also note that LDAP is not the only way to distribute CRL.

Among more popular ways we have HTTP and FTP.

M.

[narcis antonie]

Hello Marcin,

Thanks for answering. Unfortunatelly, due to security policies, I can't post the crl file.

Regarding other means to distribute the crl, I am using a http server (Microsoft IIS 5.1). The strange thing is that, if I issue "debug crypto pki t , v , m", the router, when checking the crl file (from the http server), shows me that everithing is ok and even the content of the crl file is presented (in hexadecimal) on the debug output. But when I issue the "show crypto pki crls" command, nothing is shown.  So the router does not copy to memory the crl file, even if that file is read. And now I don't even get the #705h error, it simply doesn't do anything.

Somebody told me that the copy/paste method to import the certificates does not work with crl checking on a http server. As far as you know, is that true?

Thanks again,

N.

[Marcin Latosiewicz · Accepted solution]

Narcis,

External CRL should work regardless of enrollement method.

The certificate should present a valid CDP a device could reach, what you might not have is SCEP capability check - if for whatever reason you needed it.

Regarding the 705h "error" make sure you run a release with this feature:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCee00389

What is going on during actual tunnel establishment? Can you post debug? If you need you can sanitize them.

M.

[narcis antonie]

Hello Marcin,

I managed to solve the problem.

I have decoded the crl file in openssl and found out that the file format was PEM. After converting the crl file into DER format the routers managed to interpret and load the crl to memory without any problems. I performed the conversion in openssl with the crl command.

Regarding the #705h error, I believe you were right, is was due to the IOS release I first used. The succes run was made on two 2800 platforms with 12.4(24)T5 IOS version. The unsuccesfull runs (error #705h) were made on 3700 platforms with 12.4(17) IOS version.

So, in this moment it is working great on 2800 platforms. I will test the rest on my platforms in the days to come and if I find anything conclusive about error #705h, I will post here.

Thanks again for your time.

Best regards,

Narcis Antonie

[Marcin Latosiewicz]

Cool stuff, keep us posted :-)

[Brandon Jennings]

Narcis,

This is a long shot that you will respond to this, but I am looking to do something similar. How were you able to copy/paste the CRL file? I have looked all over but haven't been able to track down  the right command.

[narcis antonie]

Hello Brandon,

I am still here :). What I meant by copy/paste, for the CRL, is that I copied the CRL file from the CA and pasted it in the root of the http server. I did not copy the content of the CRL file onto the CLI, like I am doing with the certificates. From there (http server) the routers are downloading the file into memory. The problem that I had 3 years ago was generated by the format of the CRL file, the cisco routers are expecting to download a DER file, but the CA was generating it in PEM format.

I have solved the problem by converting the file from PEM to DER using openssl just before pasting it to the root of the http server.

The command used in openssl to convert the file: crl -inform PEM -in <location of the pem crl file> -outform DER -out <where the der file should be saved and its name>

Since then, when I first posted this comment, I have encountered and overcame another problem. The certificates contained the correct CDP url, but from an unknown reason the routers did not interpret it properly and they could not download the CRL file. I have solved the problem by overriding the CDP url from the certificate (like here).

[Brandon Jennings]

Narcis,

Thanks so much for responding. So you did not copy (via tftp/scp) and source the CRL on the router flash memory correct?  You had a local machine/server that hosted the CRL file via a HTTP service and pointed the routers to that.

Thanks again for the info.

[Brandon Jennings]

Sorry to bug you one more time, as you have already been a huge help but I have run into one final issue. It appears the Router is not accepting the CRL from the http server, even though the CRL distrubtion works for another non-cisco system. I have turned off all ACLs on the involved interfaces. I get the following error 6 times when using the crypto pki crl request command

Mar 14 15:57:31.331 UTC: CRYPTO_PKI: Socket timeout

Mar 14 15:57:31.331 UTC: %PKI-3-SOCKETSELECT: Failed to select the socket.

I didn't know if you happened to have ran into something similar during your adventure. I have confirmed the CRL is DER encoded.

• Correct CRL URL is being called when using the command crypto pki crl request name
  • Mar 14 15:56:14.031 UTC: CRYPTO_PKI: (0) Requesting CRL at http://192.168.1.10/REDSA2EM-RED-CA.crl:
  • Wireshark on the http server confirms the GET request from the router
• HTTP Server is responding to the GET request
  • Confirmed via Wireshark
• The router never accepts the CRL
  • Mar 14 15:57:31.331 UTC: CRYPTO_PKI: Socket timeout
  • Mar 14 15:57:31.331 UTC: %PKI-3-SOCKETSELECT: Failed to select the socket.
  • Wireshark Retransmits
• router# show crypto pki crls   returns nothing

pertinent part of the config

crypto pki trustpoint RootCA

 enrollment terminal

 serial-number

 subject-name CN=X, OU=X, O=X, ST=X

 crl cache delete-after 43200

 revocation-check crl

 eckeypair X

 match certificate CRL override cdp url http://192.168.1.10/REDSA2EM-RED-CA.crl

 hash sha256

!

!

!

crypto pki certificate map CRL 10

 issuer-name co redsa2em-red-ca

!

I'm thinking possible IOS bug.

[narcis antonie]

Hello again Brandon,

I have tried to respond but I had some problems with this post, I could not post anything here and I have opened a ticket with the support community. And now I think they solved the problem.

When I saw I could not post here I sent you a message, but I don't think you got/saw it and so I will post the content of the message below:

"Hello Brandon,
I am trying to answer your question, but something happened with the site and its not allowing me to post anything on that discussion. I have opened a ticket with support community.
Now regarding your problem. I didn't encounter that before, but from what I understand is not a problem of the router not accepting the CRL file, it is a problem of the router not receiving it from some reason, and timing out the socket.
Perhaps you have a problem related to a long response time from the server to the router. It could be a good idea to try and connect the router closer to the server, maybe in the same LAN and see if you get the same error message.
Another idea could be to check what data reaches the router from the server, in response to the get request. If the router is connected to a Cisco switch in the direction of the server you can use SPAN technology to do that in conjunction with Wireshark.
Also check if along the path from the server to the router you have some NAT that is not working properly and changes the ports in the packets.
And lastly, what version of IOS is installed on the router, and what kind of router is it? If nothing works you can also try an IOS update.
Best regards,
Narcis Antonie"

[Brandon Jennings]

Thanks Narcis.

It turned out to be the web-server I was running didn't want to work with CRL retrieval from the Cisco devices. I could do a "copy http: flash:" with no issue. Anyway I moved to a Web-server on Ubuntu and everything worked. I am still having some issues with  revoked certificates not being denied after the CRL download, but I still have some homework to do on that front.

Thanks again for your help

[narcis antonie]

Glad it worked out.

Good luck in your endeavors!

Narcis A

[marius.dumitru]

Thanks.