11-14-2002 06:00 AM - edited 03-09-2019 01:04 AM
I'm configuring a number of devices with site-to-site VPNs, using Microsoft Windows 2000 Certificate Services to provide the certificates.
I have got the connections up and running successfully; however, when downloading the CRL I find that it does not contain the revoked certificates - hence the VPNs stay active.
Has anyone experienced similar problems, or have any suggestions as to a solution?
Many thanks, Matt
Solved! Go to Solution.
11-14-2002 08:13 AM
Which version of code are you running? You will have to be running 12.2T code for this. I've had this working in 12.2.8T. Doesnt work in 12.0 or 12.1. Also, have you tried publishing the new revoked certs on your server. The default for microsoft is 1 week. Meaning, even though you've revoked certs, the crl list wont be updated automaically, as simple as that sounds. So until the new crl is published on the server, you wont get a new updated crl list on the router. You can change the default on the server, or you can manually publish a new crl list on the server. To manually pubish the new crl list, from your certificate manager select revoked certificates and right click on it. Should be able to select publish. Don't have one sitting here in front of me but im sure thats where its at.
Kurtis
11-14-2002 08:13 AM
Which version of code are you running? You will have to be running 12.2T code for this. I've had this working in 12.2.8T. Doesnt work in 12.0 or 12.1. Also, have you tried publishing the new revoked certs on your server. The default for microsoft is 1 week. Meaning, even though you've revoked certs, the crl list wont be updated automaically, as simple as that sounds. So until the new crl is published on the server, you wont get a new updated crl list on the router. You can change the default on the server, or you can manually publish a new crl list on the server. To manually pubish the new crl list, from your certificate manager select revoked certificates and right click on it. Should be able to select publish. Don't have one sitting here in front of me but im sure thats where its at.
Kurtis
11-19-2002 08:02 AM
Thanks for the suggestions Kurtis - this is probably the case, as the routers I'm testing with only have 12.0 and 12.1. I'll give this a try later in the week, and post back with the results.
Cheers,
Matt
11-26-2002 08:17 AM
I've finally managed to get some routers with the latest version of code - 12.2(11)T.
The CRL seems to be downloaded, and if I run a debug I can see the correct serial numbers are contained within the CRL - they appear in the hex dump of the message. However, after the message has been received, the following output is shown:
05:09:45: CRYPTO_PKI: set CRL update timer with delay: 647913
05:09:45: CRYPTO_PKI: the current router time: 16:11:26 GMT Nov 26 2002
05:09:45: CRYPTO_PKI: the last CRL update time: 15:49:59 GMT Nov 26 2002
05:09:45: CRYPTO_PKI: the next CRL update time: 04:09:59 GMT Dec 4 2002
05:09:45: CRYPTO_PKI: status = 0: failed to get public key from the storage
05:09:45: CRYPTO_PKI: status = 65535: failed to get issuer pubkey in cert
05:09:45: CRYPTO_PKI: status = 0: failed to get public key from the storage
05:09:45: CRYPTO_PKI: status = 65535: failed to get issuer pubkey in cert
05:09:45: CRYPTO_PKI: transaction Unknown completed
In addition, if I clear the SAs, and then try to re-establish the connection, I can do so without any problems - even though the serial numbers of both ends of the VPN are listed in the CRL.
Has anyone experienced a similar situation - basically the IPSec software doesn't seem to check the serial numbers of either certificates against the CRL.
The output of the command 'sh crypto ca crls' is (shouldn't it list the serial numbers of the certificates?):
CRL Issuer Name:
CN = CANameHere2, OU = OrgUnitHere, O = OrgHere, L = CityHere, ST = StateHere, C = GB, EA =<16> EmailHere
LastUpdate: 15:49:59 GMT Nov 26 2002
NextUpdate: 04:09:59 GMT Dec 4 2002
Retrieved from CRL Distribution Point:
http://10.0.1.12/CertEnroll/CANameHere2.crl
Any thoughts anyone?
Many thanks,
Matt
11-27-2002 11:14 AM
Problem solved!
After quite a lot of testing, it appears that it was a timing issue - even though I had downloaded the latest CRL, and (thought I'd) closed the connections between the routers, I hadn't - after rebooting the routers the VPN wouldn't come back up, so obviously something was still hanging around.
Thanks to everyone for their suggestions & help.
Regards,
Matt
05-26-2003 05:59 AM
Well, looking at the problem described - it's my dream to get CRL on Router 3620 with IOS=12.2(11)T6, file=c3620-ik9s-mz.122-11.T6.bin.
Configuration looks like this :
ip domain name lmt.lv
ip host tau.2k.mydom.net 10.10.2.49
ip host tau 10.10.2.49
!
crypto ca trustpoint LMT-PKI
enrollment mode ra
enrollment url http://tau:80/certsrv/mscep/mscep.dll
usage ike
serial-number
ip-address 10.10.90.240
crl query ldap://10.10.2.49
If I try to get CRL, it seems router is trying LDAP on broadcast address, output of "debug crypto pki transactions" :
r-c3620-vpn1(config)#crypto ca crl request LMT-PKI
r-c3620-vpn1(config)#ldap search: server=255.255.255.255, base=CN=TestCA,CN=tau,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=2k,DC=mydom,DC=net, attribute=certificateRevocationList
: scope=0, filter=objectclass=cRLDistributionPoint
May 26 16:37:58.993: CRYPTO_PKI:ldap_bind ERROR: status = 82
May 26 16:37:58.993: CRYPTO_PKI: ldap bind error: status = 82
May 26 16:37:58.993: CRYPTO_PKI: transaction GetCRL completed
I suppose it should go to the address specified with "crl query ldap://10.10.2.49" but it does not ?
I have successfully got certificates of the CA and the router itself :
r-c3620-vpn1>show crypto ca certificates
Certificate
Status: Available
Certificate Serial Number: 610D081E000000000009
Certificate Usage: General Purpose
Issuer:
CN = TestCA
OU = LMT-VPN
O = LMT-VPN
L = Riga
ST = Riga
C = LV
EA =<16> Kaspar.Caun@domain.lv
Subject:
Name: r-c3620-vpn1.lmt.lv
IP Address: 10.10.90.240
Serial Number: 21464125
OID.1.2.840.113549.1.9.2 = r-c3620-vpn1.lmt.lv
OID.1.2.840.113549.1.9.8 = 10.10.90.240
OID.2.5.4.5 = 21464125
CRL Distribution Point:
ldap:///CN=TestCA,CN=tau,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=2k,DC=mydom,DC=net?certificateRevocationList?base?objectclass=cRLDistributionPoint
Validity Date:
start date: 14:29:10 EEST May 15 2003
end date: 14:29:10 EEST May 14 2005
renew date: 02:00:00 EET Jan 1 1970
Associated Trustpoints: LMT-PKI
CA Certificate
Status: Available
Certificate Serial Number: 49F2340E73872AB44CCAD9CB46657697
Certificate Usage: General Purpose
Issuer:
CN = TestCA
OU = LMT-VPN
O = LMT-VPN
L = Riga
ST = Riga
C = LV
EA =<16> Kaspar.Caun@domain.lv
Subject:
CN = TestCA
OU = LMT-VPN
O = LMT-VPN
L = Riga
ST = Riga
C = LV
EA =<16> Kaspar.Caun@domain.lv
CRL Distribution Point:
ldap:///CN=TestCA,CN=tau,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=2k,DC=mydom,DC=net?certificateRevocationList?base?objectclass=cRLDistributionPoint
Validity Date:
start date: 12:25:09 EEST May 15 2003
end date: 12:30:06 EEST May 15 2005
Associated Trustpoints: LMT-PKI
Anybody can tell where is my fault ?
Many thanks !
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide