none
From time to time, I can't verify the expiration of my client certificate on IIS.

    Question

  • I have a IIS web server and a CA(AD CS) server built on a 2008R2 virtual machine.
    I require a client certificate in order to access the web server.

    It works very well but FROM TIME TO TIME, a 403 error code is returned.
    According to the trace log(FailedReqLogFiles), a 0x80092013 error occurs.
    Once this 403 error occurs, it last for about an hour and then everything goes back to normal.

    In order to find out what is the problem, I have done setup:

    - CRL has a publication time of 1 hour
    - (Delta CRL) has a publication time of 30minutes.

    also:
    - Both web server and CA server are not on a domain but a workgroup
    - The CA certificate is registered on the web server & client on the root & intermediate certificate registrar.
    - Both setups are patched to the latest windows update

    As far as I've checked the log:
    - on the web server log(source: CAPI2), there is an event id 53 at almost every hour for both the CRL & delta CRL
    but before the problem occurs the event id 53 is only reported on the delta CRL and nothing on the CRL.
    - By the way, System32\config\systemprofile\AppData\LocalLow\Microsoft\X509Objects, the .crl file for the problematic update is only present on the delta CRL.
    - On the CA server's IIS access log, there is just the delta CRL access that is registered.
    - Below is the log on the CA server IIS's access log (XXX-CA is for anonymous sake):
    2014-04-16 10:51:34 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1).crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 218
    2014-04-16 10:51:39 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1)+.crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 202
    2014-04-16 11:52:05 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1)+.crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 265
    2014-04-16 12:52:22 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1).crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 218
    2014-04-16 12:52:28 fe80::f99a:eb13:7c7b:1de4%10 GET /CertEnroll/XXX-CA(1)+.crl - 80 - fe80::7993:d27a:af9f:170%10 Microsoft-CryptoAPI/6.1 200 0 0 202
    - I think that the 403 error is due to the fact this CRL is not getting reached but why would this happen?
    - Is there an other way than to restart the OS in order to clear this problem in a shorter time than 1 hour?
    side note:
    - this problem happens on the client setup too.
    - the log is shorten but if there is any filter to apply to get better information, please tell me.

    I would appreciate any helps on this matter!

    nb:
    this is a translation from a Japanese text.
    Friday, April 18, 2014 1:16 AM

Answers

  • Hi,

    In addition, you can refer to this KB article below to troubleshoot this issue based on specific error code:

    Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes

    http://support.microsoft.com/kb/318380/en-au

    Best Regards,

    Amy

    Monday, April 21, 2014 6:10 AM
  • Hi,

    The error message will occur if IIS cannot download CRLs of the client certificate, in other words, if the CA is shut down or there are network connectivity issues between web server and CA when Internet Information Services try to download the client certificate’s CRL.

    Therefore, please make sure that there is no network connectivity issue between the web server and CA, you can find the IP address of the problem CDP server then add an entry to the HOSTS file on the IIS computer.

    Here are some related KB articles below I suggest you refer to:

    IIS returns HTTP "403.13 Client Certificate Revoked" error message although certificate is not revoked

    http://support.microsoft.com/kb/294305/en-us

    You receive a "403.13 client certificate revoked" error message when you connect to a computer that is running Windows Server 2003 and Internet Information Services 6.0

    http://support.microsoft.com/kb/884115/en-us

    Best Regards,

    Amy

    Friday, April 25, 2014 7:23 AM
  • It was resolved by applying the hotfix KB2666300. 

    It seems not included in the Windows Update because it is not a Security issue, must be downloaded separately. 

    Cause is not set up an OCSP server for CRL check, but because it was enabled using OCSP (Online Certificate Status Protocol) in the properties of the CA, with an error when the Web server is accessed by the URL of the OCSP in CA it was due to the failure to put away, and that would no longer be access to the URL of the CRL later. 

    Contact from paid support window, taught me the above KB. 
    Thank you to the following people who your cooperation.

    (I'm sorry in machine translation by Google Translate)

    • Marked as answer by 冨田貴士 Monday, May 12, 2014 11:38 AM
    Monday, May 12, 2014 11:37 AM

All replies

  • Hi,

    1. Can you confirm that CDP of the SSL certificate you use, contains both CRL and delta CRL (CRL+) location?

    2. When 403 error occurs did you try to download CRL and CRL+ from the web server (to see if it is accessible at the time of 403 error)?

    3. If you successfully downloaded CRL and CRL+ during 403 error, did you open them and validate Effective date and Next update attributes?

    4. Did you configure CRL overlap periods: http://technet.microsoft.com/en-us/library/cc731104.aspx ?


    Did my post help you or make you laugh? Don't forget to click the Helpful vote :) If I answered your question please mark my post as an Answer.

    Friday, April 18, 2014 7:17 PM
  • Hi,

    In addition, you can refer to this KB article below to troubleshoot this issue based on specific error code:

    Description of Microsoft Internet Information Services (IIS) 5.0 and 6.0 status codes

    http://support.microsoft.com/kb/318380/en-au

    Best Regards,

    Amy

    Monday, April 21, 2014 6:10 AM
  • Thank you for reply.

    I looked some files logged by IIS's Failed request trace(placed at inetpub/logs/FailedReqLogFiles/*.xml).
    STATUS_CODE is 403.13

    ModuleName IIS Web Core 
    Notification 1 
    HttpStatus 403 
    HttpReason Forbidden 
    HttpSubStatus 13 
    ErrorCode 2148081683 
    ConfigExceptionInfo  
    Notification BEGIN_REQUEST 
    ErrorCode 失効サーバーがオフラインのため、失効の関数は失効を確認できませんでした。 (0x80092013) 
    In English, Maybe .. 'The revocation function was unable to check revocation because the revocation server was offline.')

    But, Cause it occurs, how to recover without a reboot of the OS is unknown.
    Monday, April 21, 2014 7:26 AM
  • Thank you for your reply.

    I am using jmeter in order to automatically access the log so I didn't try 1 & 2.
    But i've tried 1 & 2 on the live server(which,unlike the test environment, is not patched to the latest version).

    I have downloaded the CRT & CRL from the url specified in the client certificate via IE.

    [1]CRL Distribution Point
         Distribution Point Name:
              Full Name:
                   URL=http://win-msprl0t325o/CertEnroll/XXX-CA.crl
    [1]Authority Info Access
         Access Method=online certification protocol (1.3.6.1.5.5.7.48.1)
         Alternative Name:
              URL=http://win-msprl0t325o/CertEnroll/WIN-MSPRL0T325O_XXX-CA.crt

    Also I was able to download the delta CRL as http://win-msprl0t325o/CertEnroll/XXX-CA+.crl

    3. This is the content of the files downloaded via IE:

    Date as of now: 2014/04/21 15:30
    ・CRL file
    Valid start time:2014/04/18 10:48:59
    next update:2014/04/25 23:08:59
    next CRL creation:2014/04/25 10:58:59
    CRL number:00 b7
     
    ・CRL+ file
    Valid start time:2014/04/21 10:48:59
    next update:2014/04/22 23:08:59
    next CRL creation:2014/04/22 10:58:59
    CRL number:00 ba
    Delta CRL indicator:00 b7

    4. I did not as I think the default settings are just fine.
     
    By restarting the OS, I can recover from this 403 error 
    but is there an other way than to restart the OS to recover from this?
    I was unable to recover from this problem by restarting IIS via the IIS manager.

    nb:
    this is a translation from a Japanese text.
    Monday, April 21, 2014 7:28 AM
  • Hi,

    The error message will occur if IIS cannot download CRLs of the client certificate, in other words, if the CA is shut down or there are network connectivity issues between web server and CA when Internet Information Services try to download the client certificate’s CRL.

    Therefore, please make sure that there is no network connectivity issue between the web server and CA, you can find the IP address of the problem CDP server then add an entry to the HOSTS file on the IIS computer.

    Here are some related KB articles below I suggest you refer to:

    IIS returns HTTP "403.13 Client Certificate Revoked" error message although certificate is not revoked

    http://support.microsoft.com/kb/294305/en-us

    You receive a "403.13 client certificate revoked" error message when you connect to a computer that is running Windows Server 2003 and Internet Information Services 6.0

    http://support.microsoft.com/kb/884115/en-us

    Best Regards,

    Amy

    Friday, April 25, 2014 7:23 AM
  • Hi,

    Do you have any updates?

    Regards,

    Amy

    Monday, April 28, 2014 10:03 AM
  • Only on the Delta CRL, Hummmm

    Check that :

    http://blogs.technet.com/b/lrobins/archive/2008/12/29/publishing-delta-crls-on-iis-7.aspx

    bye bye

    Wednesday, May 07, 2014 2:25 PM
  • It was resolved by applying the hotfix KB2666300. 

    It seems not included in the Windows Update because it is not a Security issue, must be downloaded separately. 

    Cause is not set up an OCSP server for CRL check, but because it was enabled using OCSP (Online Certificate Status Protocol) in the properties of the CA, with an error when the Web server is accessed by the URL of the OCSP in CA it was due to the failure to put away, and that would no longer be access to the URL of the CRL later. 

    Contact from paid support window, taught me the above KB. 
    Thank you to the following people who your cooperation.

    (I'm sorry in machine translation by Google Translate)

    • Marked as answer by 冨田貴士 Monday, May 12, 2014 11:38 AM
    Monday, May 12, 2014 11:37 AM
  • Hi,

    Thank you for you sharing,I am glad to hear that this issue is solved!

    Please feel free to let us know if there are any further requirements.

    Regards,

    Amy

    Tuesday, May 13, 2014 1:35 AM