Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
11402
Views
15
Helpful
9
Replies

ASA 8.4(6) "Unable to retrieve or verify CRL"

Go to solution
Nicola Volpini
Level 1
Level 1

‎12-18-2013 04:55 AM

Hi,

I configured our ASA to fetch a CRL provided via  our Linux CA. The crl is exported via Tinyca as a crl file and served by Apache.

The file is reachable by the ASA and up to date, I see an http 200 (OK). Despite that I get a "Unable to retrieve or verify CRL".

The ASA is configured as following:

crypto ca trustpoint LINUX-CA-TP
 revocation-check crl none
 enrollment terminal
 crl configure
  policy static
  url 1 http://<ca-url>/issuingca.crl
  no protocol ldap
  no protocol scep

Enabling debug and trying a "crypto ca crl request LINUX-CA-TP":

ASA (config)# crypto ca crl request LINUX-CA-TP

CRYPTO_PKI: CRL is being polled from CDP http://<ca-url>/issuingca.crl.

Unable to retrieve or verify CRL
vpn015pi(config)# 
CRYPTO_PKI: HTTP response header:
 HTTP/1.1 200 OK
Date: Wed, 18 Dec 2013 12:49:01 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Wed, 18 Dec 2013 09:50:20 GMT
ETag: ...
Accept-Ranges: bytes
Content-Length: 1170
Connection: close
Content-Type: application/x-pkcs7-crl


CRYPTO_PKI: transaction HTTPGetCRL completed

I'm a bit puzzled. The error is not really saying where the ASA is exactly failing!

Thanks

1 person had this problem
Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
Vaclav Janecek
Level 1
Level 1

‎01-13-2016 12:40 AM

Hi.

I know this is late response, but I found solution.

My CA was created via openssl commands and crl was coppied to www server. I installed CA certificate to ASA and I tried to check CRL. But it failed. This is output of debug:

CRYPTO_PKI: CRL is being polled from CDP http://x.x.x.x/ca/root-ca/root-ca.crl.
crypto_pki_req(0x00007fff2b9e3900, 24, ...)
CRYPTO_PKI: Crypto CA req queue size = 1.
Crypto CA thread wakes up!
CRYPTO_PKI: http connection opened
CRYPTO_PKI: content dump count 81----------
CRYPTO_PKI: For function crypto_http_send
GET /ca/root-ca/root-ca.crl HTTP/1.0
Host: x.x.x.x

CRYPTO_PKI: For function crypto_http_send
CRYPTO_PKI: content dump-------------------

CRYPTO_PKI: HTTP response header:
 HTTP/1.1 200 OK
Date: Wed, 13 Jan 2016 08:10:01 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Tue, 12 Jan 2016 10:12:50 GMT
ETag: "31c-529204bc05097"
Accept-Ranges: bytes
Content-Length: 796
Connection: close
Content-Type: application/x-pkcs7-crl


CRYPTO_PKI: CRL data2d 2d 2d 2d 2d 42 45 47 49 4e 20 58 35 30 39 20 | -----BEGIN X509 
.
.
.

CRYPTO_PKI: transaction HTTPGetCRL completedCrypto CA thread sleeps!
CRYPTO_PKI: Failed to retrieve CRL for trustpoint: ASDM_TrustPoint3.
 Retrying with next CRL DP...

Because crl file was downloaded, I verify my crl with openssl command on my linux server:

openssl crl -inform PEM -text -in crl/root-ca/root-ca.crl 
Certificate Revocation List (CRL):
 Version 2 (0x1)
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: 
 Last Update: Jan 12 10:09:33 2016 GMT
 Next Update: Jan 11 10:09:33 2017 GMT
 CRL extensions:
 X509v3 Authority Key Identifier: 
 keyid:E9:5E:25:61:EB:5D:9D:7E:2E:1A:3A:DA:71:B3:7B:C2:55:8D:59:66

 Authority Information Access: 
 CA Issuers - URI:http://x.x.x.x/ca/root-ca/root-ca.cer

 X509v3 CRL Number: 
 1
No Revoked Certificates.
 Signature Algorithm: sha256WithRSAEncryption
.
.
.

-----BEGIN X509 CRL-----
.
.
.
-----END X509 CRL-----

I founded that CRL file is in PEM format. And because another avalaible format of CRL is DER format I converted it to DER format and copied it to www server.

openssl crl -inform PEM -outform DER -in crl/root-ca/root-ca.crl -out crl/root-ca/root-ca-der.crl

After that I tried to request CRL file from my ASA again and it was successfull.

 CRYPTO_PKI: CRL is being polled from CDP http://x.x.x.x/ca/root-ca/root-ca.crl.
crypto_pki_req(0x00007fff2b9e3900, 24, ...)
CRYPTO_PKI: Crypto CA req queue size = 1.
Crypto CA thread wakes up!
CRYPTO_PKI: http connection opened
CRYPTO_PKI: content dump count 81----------
CRYPTO_PKI: For function crypto_http_send
GET /ca/root-ca/root-ca.crl HTTP/1.0
Host: x.x.x.x

CRYPTO_PKI: For function crypto_http_send
CRYPTO_PKI: content dump-------------------

CRYPTO_PKI: HTTP response header:
 HTTP/1.1 200 OK
Date: Wed, 13 Jan 2016 08:28:08 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Wed, 13 Jan 2016 08:25:54 GMT
ETag: "227-52932eb2c1926"
Accept-Ranges: bytes
Content-Length: 551
Connection: close
Content-Type: application/x-pkcs7-crl


CRYPTO_PKI: CRL data30 
.
.
.


CRYPTO_PKI: Found suitable tp
CRYPTO_PKI: Found suitable tp
CRYPTO_PKI: Failed to create name objects to compare DNs. status = 1795
CRYPTO_PKI(select cert) subject = ...
CRYPTO_PKI: Found a subject match - inserting the following cert record into certList
CRYPTO_PKI: Storage context locked by thread Crypto CA

CRYPTO_PKI: inserting CRL
CRYPTO_PKI: set CRL update timer with delay: 31455520
CRYPTO_PKI: the current device time: 08:30:53 UTC Jan 13 2016

CRYPTO_PKI: the last CRL update time: 10:09:33 UTC Jan 12 2016
CRYPTO_PKI: the next CRL update time: 10:09:33 UTC Jan 11 2017
CRYPTO_PKI: CRL cache delay being set to: 3600000
CRYPTO_PKI: Storage context released by thread Crypto CA

CRYPTO_PKI: transaction HTTPGetCRL completedCrypto CA thread sleeps!

View solution in original post

9 Replies 9

Go to solution
m.kafka
Level 4
Level 4

‎12-19-2013 03:56 PM

Hi,

what level is the debug? which debug exactly? I have seen more detailed output from "ca transactions" before...

0 Helpful

Go to solution
Nicola Volpini
Level 1
Level 1
In response to m.kafka

‎01-06-2014 05:24 AM

Hi, thanks for the answer.
I'm using the following:

debug crypto ca messages 255

debug crypto ca transactions 255

This output is interesting (omitting the CRL full url, which is correct):

CRYPTO_PKI: Starting CRL revocation check.
CRYPTO_PKI: Attempting to find cached CRL for CDP http://
CRYPTO_PKI: CRL not found in cache and not being retrieved.

CRYPTO_PKI: CRL is being polled from CDP http://

CRYPTO_PKI: valid cert with warning.

CRYPTO_PKI: valid cert status.

Seems like it's not verifying the certificate due to the CRL not being correctly fetched...

0 Helpful

Go to solution
m.kafka
Level 4
Level 4
In response to Nicola Volpini

‎01-06-2014 06:04 AM

Hi Nicola,

are you sure that the ASA can resolve "http:///issuingca.crl" try:

copy http:///issuingca.crl flash://

Rgds, MiKa

0 Helpful

Go to solution
Nicola Volpini
Level 1
Level 1
In response to m.kafka

‎01-06-2014 06:20 AM

hi!

Seems like it works fine:

Writing file disk0:/issuingca.crl...

!

1007 bytes copied in 0.90 secs

(ciscoasa)# dir

Directory of disk0:/

...

267    -rwx  1007         15:17:53 Jan 06 2014  issuingca.crl

...

At least it gets the file!

0 Helpful

Go to solution
m.kafka
Level 4
Level 4
In response to Nicola Volpini

‎01-09-2014 10:00 AM

Not sure, it doesn't tell a lot... Is your Linux CA configured for CA/RA or CA? dou have the complete trustchain? Did you verify the crl with external tools e.g. openssl?

The "valid cert with warning" is a little bit vague, any other debug output?

0 Helpful

Go to solution
Nicola Volpini
Level 1
Level 1
In response to m.kafka

‎01-21-2014 07:51 AM

Hi, I'm pasting the debug of the entire "ca" section with level 255.

I have the complete trustchain, yes, and the linuxca is an intermediate certificate. As a note: I added each cert of the trustchain as a separate TRUSTPOINT in the ASA. I'm suspecting it should be better to concatenate them and include them in a single trustpoint, or?

Openssl can validate the entire chain, yes.

I'm not sure what you mean by CA/RA, sorry...

Here's the debug!

CERT_API: Authenticate session 0x03edaf95, non-blocking cb=0x08ec46d0
CERT API thread wakes up!
CERT_API: process msg cmd=0, session=0x03edaf95
CERT_API: Async locked for session 0x03edaf95
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Found cert in database. 
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Found cert in database. 
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Found cert in database. 
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Cert record not found, returning E_NOT_FOUND
CRYPTO_PKI: Cert not found in database. 
CRYPTO_PKI: Looking for suitable trustpoints...
CRYPTO_PKI: Storage context locked by thread CERT API
CRYPTO_PKI: Found a suitable authenticated trustpoint LINUX-CA-TP.
CRYPTO_PKI(make trustedCerts list)CRYPTO_PKI:check_key_usage: ExtendedKeyUsage OID = 1.3.6.1.5.5.7.3.2
CRYPTO_PKI:check_key_usage:Key Usage check OK
CRYPTO_PKI: Certificate validation: Successful, status: 0. Attempting to retrieve revocation status if necessary
CRYPTO_PKI: Select DER crl(cn= linux issuing CA,c=ML)
CRYPTO_PKI: Spawned retrieval of optional CRL for trustpoint LINUX-CA-TPcrypto_pki_req(0xac773ee0, 24, ...)
CRYPTO_PKI: Crypto CA req queue size = 1.
CRYPTO_PKI:Certificate validated. serial number: 35, subject name:  cn=nicola volpini infra CRL revok test,c=ML.
CRYPTO_PKI: Storage context released by thread CERT API
CRYPTO_PKI: Certificate validated without revocation check
CERT_API: calling user callback=0x08ec46d0 with status=0
CERT_API: Close session 0x03edaf95 asynchronously
CERT_API: Async unlocked for session 0x03edaf95
Crypto CA thread wakes up!
CERT_API: process msg cmd=1, session=0x03edaf95
CERT_API: Async locked for session 0x03edaf95
CERT_API: Async unlocked for session 0x03edaf95
CERT API thread sleeps!
CRYPTO_PKI: http connection opened
CRYPTO_PKI: content dump count 98----------
CRYPTO_PKI: For function crypto_http_send
GET /ca/linuxissuingca.crl HTTP/1.0
Host: ca.services..com
CRYPTO_PKI: For function crypto_http_send
CRYPTO_PKI: content dump-------------------
CRYPTO_PKI: Failed to retrieve CRL for trustpoint: LINUX-CA-TP. status 106.
Crypto CA thread sleeps!
CERT_API: Authenticate session 0x040e517b, non-blocking cb=0x08ec46d0
CERT API thread wakes up!
CERT_API: process msg cmd=0, session=0x040e517b
CERT_API: Async locked for session 0x040e517b
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Found cert in database. 
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Found cert in database. 
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Found cert in database. 
CRYPTO_PKI: Checking to see if an identical cert is
 already in the database...
CRYPTO_PKI: looking for cert in handle=0xab6f9b7c, digest=
CRYPTO_PKI: Cert record not found, returning E_NOT_FOUND
CRYPTO_PKI: Cert not found in database. 
CRYPTO_PKI: Looking for suitable trustpoints...
CRYPTO_PKI: Storage context locked by thread CERT API
CRYPTO_PKI: Found a suitable authenticated trustpoint LINUX-CA-TP.
CRYPTO_PKI(make trustedCerts list)CRYPTO_PKI:check_key_usage: ExtendedKeyUsage OID = 1.3.6.1.5.5.7.3.2
CRYPTO_PKI:check_key_usage:Key Usage check OK
CRYPTO_PKI: Certificate validation: Successful, status: 0. Attempting to retrieve revocation status if necessary
CRYPTO_PKI: Select DER crl(cn= linux issuing CA,c=ML)
CRYPTO_PKI: Spawned retrieval of optional CRL for trustpoint LINUX-CA-TPcrypto_pki_req(0xac773ee0, 24, ...)
CRYPTO_PKI: Crypto CA req queue size = 1.
CRYPTO_PKI:Certificate validated. serial number: 35, subject name:  cn=nicola volpini infra CRL revok test,c=ML.
CRYPTO_PKI: Storage context released by thread CERT API
CRYPTO_PKI: Certificate validated without revocation check
CERT_API: calling user callback=0x08ec46d0 with status=0
CERT_API: Close session 0x040e517b asynchronously
CERT_API: Async unlocked for session 0x040e517b
Crypto CA thread wakes up!
CRYPTO PKI: CRL poll request denied; previous attempt failed.CRYPTO_PKI: Failed to retrieve CRL for trustpoint: LINUX-CA-TP. status 106.
Crypto CA thread sleeps!
CERT_API: process msg cmd=1, session=0x040e517b
CERT_API: Async locked for session 0x040e517b
CERT_API: Async unlocked for session 0x040e517b
CERT API thread sleeps!
CRYPTO_PKI: Attempting to find tunnel group for cert with serial number: 35, subject name: cn=nicola volpini infra CRL revok test,c=ML, issuer_name: cn= linux issuing CA,c=ML.
CRYPTO_PKI: Processing map rules for CERTMAP--VPN.
CRYPTO_PKI: certificate contains 8 extensions.
CRYPTO_PKI: certificate contains extension OID: 
55 1d 13 
CRYPTO_PKI: certificate contains extension OID: 
60 86 48 01 86 f8 42 01 01 
CRYPTO_PKI: certificate contains extension OID: 
55 1d 0e 
CRYPTO_PKI: certificate contains extension OID: 
55 1d 23 
CRYPTO_PKI: certificate contains extension OID: 
55 1d 12 
CRYPTO_PKI: certificate contains extension OID: 
55 1d 11 
CRYPTO_PKI: certificate contains extension OID: 
55 1d 0f 
CRYPTO_PKI: certificate contains extension OID: 
55 1d 25 
CRYPTO_PKI: Processing map CERTMAP--VPN sequence 10...
CRYPTO_PKI: Match of issuer-name field to map PASSED. Peer cert field:  = cn= linux issuing CA,c=ML, map rule: issuer-name   co .
CRYPTO_PKI: Peer cert has been authorized by map: CERTMAP--VPN sequence: 10.
CRYPTO_PKI: Tunnel Group Match on map CERTMAP--VPN sequence # 10.  Group name is -VPN

Thanks!

0 Helpful

Go to solution
KAI FALKENBERG
Level 1
Level 1
In response to Nicola Volpini

‎09-25-2014 06:14 AM

Well??? Any solutions???

 

0 Helpful

Go to solution
Vaclav Janecek
Level 1
Level 1

‎01-13-2016 12:40 AM

Hi.

I know this is late response, but I found solution.

My CA was created via openssl commands and crl was coppied to www server. I installed CA certificate to ASA and I tried to check CRL. But it failed. This is output of debug:

CRYPTO_PKI: CRL is being polled from CDP http://x.x.x.x/ca/root-ca/root-ca.crl.
crypto_pki_req(0x00007fff2b9e3900, 24, ...)
CRYPTO_PKI: Crypto CA req queue size = 1.
Crypto CA thread wakes up!
CRYPTO_PKI: http connection opened
CRYPTO_PKI: content dump count 81----------
CRYPTO_PKI: For function crypto_http_send
GET /ca/root-ca/root-ca.crl HTTP/1.0
Host: x.x.x.x

CRYPTO_PKI: For function crypto_http_send
CRYPTO_PKI: content dump-------------------

CRYPTO_PKI: HTTP response header:
 HTTP/1.1 200 OK
Date: Wed, 13 Jan 2016 08:10:01 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Tue, 12 Jan 2016 10:12:50 GMT
ETag: "31c-529204bc05097"
Accept-Ranges: bytes
Content-Length: 796
Connection: close
Content-Type: application/x-pkcs7-crl


CRYPTO_PKI: CRL data2d 2d 2d 2d 2d 42 45 47 49 4e 20 58 35 30 39 20 | -----BEGIN X509 
.
.
.

CRYPTO_PKI: transaction HTTPGetCRL completedCrypto CA thread sleeps!
CRYPTO_PKI: Failed to retrieve CRL for trustpoint: ASDM_TrustPoint3.
 Retrying with next CRL DP...

Because crl file was downloaded, I verify my crl with openssl command on my linux server:

openssl crl -inform PEM -text -in crl/root-ca/root-ca.crl 
Certificate Revocation List (CRL):
 Version 2 (0x1)
 Signature Algorithm: sha256WithRSAEncryption
 Issuer: 
 Last Update: Jan 12 10:09:33 2016 GMT
 Next Update: Jan 11 10:09:33 2017 GMT
 CRL extensions:
 X509v3 Authority Key Identifier: 
 keyid:E9:5E:25:61:EB:5D:9D:7E:2E:1A:3A:DA:71:B3:7B:C2:55:8D:59:66

 Authority Information Access: 
 CA Issuers - URI:http://x.x.x.x/ca/root-ca/root-ca.cer

 X509v3 CRL Number: 
 1
No Revoked Certificates.
 Signature Algorithm: sha256WithRSAEncryption
.
.
.

-----BEGIN X509 CRL-----
.
.
.
-----END X509 CRL-----

I founded that CRL file is in PEM format. And because another avalaible format of CRL is DER format I converted it to DER format and copied it to www server.

openssl crl -inform PEM -outform DER -in crl/root-ca/root-ca.crl -out crl/root-ca/root-ca-der.crl

After that I tried to request CRL file from my ASA again and it was successfull.

 CRYPTO_PKI: CRL is being polled from CDP http://x.x.x.x/ca/root-ca/root-ca.crl.
crypto_pki_req(0x00007fff2b9e3900, 24, ...)
CRYPTO_PKI: Crypto CA req queue size = 1.
Crypto CA thread wakes up!
CRYPTO_PKI: http connection opened
CRYPTO_PKI: content dump count 81----------
CRYPTO_PKI: For function crypto_http_send
GET /ca/root-ca/root-ca.crl HTTP/1.0
Host: x.x.x.x

CRYPTO_PKI: For function crypto_http_send
CRYPTO_PKI: content dump-------------------

CRYPTO_PKI: HTTP response header:
 HTTP/1.1 200 OK
Date: Wed, 13 Jan 2016 08:28:08 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Wed, 13 Jan 2016 08:25:54 GMT
ETag: "227-52932eb2c1926"
Accept-Ranges: bytes
Content-Length: 551
Connection: close
Content-Type: application/x-pkcs7-crl


CRYPTO_PKI: CRL data30 
.
.
.


CRYPTO_PKI: Found suitable tp
CRYPTO_PKI: Found suitable tp
CRYPTO_PKI: Failed to create name objects to compare DNs. status = 1795
CRYPTO_PKI(select cert) subject = ...
CRYPTO_PKI: Found a subject match - inserting the following cert record into certList
CRYPTO_PKI: Storage context locked by thread Crypto CA

CRYPTO_PKI: inserting CRL
CRYPTO_PKI: set CRL update timer with delay: 31455520
CRYPTO_PKI: the current device time: 08:30:53 UTC Jan 13 2016

CRYPTO_PKI: the last CRL update time: 10:09:33 UTC Jan 12 2016
CRYPTO_PKI: the next CRL update time: 10:09:33 UTC Jan 11 2017
CRYPTO_PKI: CRL cache delay being set to: 3600000
CRYPTO_PKI: Storage context released by thread Crypto CA

CRYPTO_PKI: transaction HTTPGetCRL completedCrypto CA thread sleeps!

Go to solution
Nicola Volpini
Level 1
Level 1
In response to Vaclav Janecek

‎07-15-2016 07:49 AM

Thanks! It's never too late, your answer will help the community :)

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents