<div>
<div>Hi,</div>

<div>I’ve problems with the certificate revocation check.<br />
The system:<br />
StrongSwan v5.3.5 on Ubuntu 16.06, the CA is an Active Directory Certificate Services Enterprise CA on Windows Server 2012 R2.<br />
When I establish the connection from a Windows 10 client I see the following in the log regarding the revocation check:</div>

<div>16[CFG] <GP-ANY-VPN|487> checking certificate status of "CN=XXXXXXXXXXX"<br />
16[CFG] <GP-ANY-VPN|487>   requesting ocsp status from 'http://XXXXXXXXXX/ocsp' ...<br />
16[ASN] <GP-ANY-VPN|487> L0 - OCSPResponse:<br />
16[ASN] <GP-ANY-VPN|487> L1 - responseStatus:<br />
16[ASN] <GP-ANY-VPN|487> => 1 bytes @ 0x7f33f8007944<br />
16[ASN] <GP-ANY-VPN|487>    0: 06                                               .<br />
16[LIB] <GP-ANY-VPN|487>   ocsp response status: unauthorized<br />
16[LIB] <GP-ANY-VPN|487> building CRED_CERTIFICATE - X509_OCSP_RESPONSE failed, tried 2 builders<br />
16[CFG] <GP-ANY-VPN|487> parsing ocsp response failed<br />
16[CFG] <GP-ANY-VPN|487> ocsp check failed, fallback to crl<br />
16[CFG] <GP-ANY-VPN|487>   fetching crl from 'ldap:///CN=XXXXXXXXX,CN=XXXXXXXXX,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXX,DC=XX?certificateRevocationList?base?objectClass=cRLDistributionPoint' ...<br />
16[LIB] <GP-ANY-VPN|487> LDAP bind to 'ldap:///CN=XXXXXXXXX,CN=XXXXXXXXX,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=XXXXXXX,DC=XX?certificateRevocationList?base?objectClass=cRLDistributionPoint' failed: Can't contact LDAP server<br />
16[CFG] <GP-ANY-VPN|487> crl fetching failed<br />
16[CFG] <GP-ANY-VPN|487> certificate status is not available</div>

<div><br />
Problem 1: OCSP Unauthorized<br />
Unfortunately I’m not an expert in this Base64 / ASN.1 system used in the OCSP request. I see the following in the IIS log:</div>

<div>2016-07-27 09:35:31 172.16.4.13 GET /ocsp/MFQwUjBQME4wTDAJBgUrDgMCGgUABBSpFRoRLl4rcMKsoKQ2skpbAsaTMQQU9mmkRYx+H3QQpHLJYudaoIzrshgCEy8AAAACRdcD5m18LmcAAAAAAAI= - 81 - 172.16.4.13 Microsoft-CryptoAPI/6.1 - 200 0 0 0</div>

<div>I tried to decode the request manually</div>

<div>I got back the following:</div>

<div>30 54<br />
  30 52<br />
    30 50<br />
      30 4E<br />
        30 4C<br />
          30 09<br />
            06 05 2B0E03021A (OBJECT IDENTIFIER 1.3.14.3.2.26 - SHA1 Hash OID)<br />
            05 00 <br />
          04 14 A9151A112E5E2B70C2ACA0A436B24A5B02C69331<br />
          04 14 F669A4458C7E1F7410A472C962E75AA08CEBB218 - (this is the Authority key identifier in my cert)<br />
          02 13 2F0000000245D703E66D7C2E67000000000002 - (this should be the serial number of my cert)</div>

<div> </div>

<div>According to the strongswan log (and this can be seen in the certificate on the Windows also):</div>

<div>16[ASN] <GP-ANY-VPN|487> L2 - serialNumber:<br />
16[ASN] <GP-ANY-VPN|487> => 19 bytes @ 0x7f33f800261f<br />
16[ASN] <GP-ANY-VPN|487>    0: 2F 00 00 00 08 EC 3A 31 9D AA 10 F8 43 00 00 00  /.....:1....C...<br />
16[ASN] <GP-ANY-VPN|487>   16: 00 00 08                                         ...</div>

<div>The serial number of the certificate and the serial number in the OCSP request is different. It looks like a bug to me.<br />
BTW. I don’t understand why the OCSP request’s row data isn’t getting logged with “asn 4” loglevel. </div>

<div> </div>

<div>Problem 2: CRL validation<br />
It is normal here that the LDAP validation is failing as the linux has no access to the LDAP server. On the other side, the the CDP attribute of the certificate also contains HTTP uri for the CRL. It is possible to configure in the strongswan, to try not just the first CDP, or I’ve no other option than, to remove the LDAP path from the CDP attribute?</div>

<div> </div>

<div>Thank you,<br />
SUF</div>
</div>