cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11501
Views
15
Helpful
9
Replies

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

Nicola Volpini
Level 1
Level 1

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 Accepted Solution

Accepted Solutions

Vaclav Janecek
Level 1
Level 1

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

m.kafka
Level 4
Level 4

Hi,

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

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...

Hi Nicola,

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

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

Rgds, MiKa

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!

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?

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!

Well??? Any solutions???

 

Vaclav Janecek
Level 1
Level 1

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!

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