现象：
调用CertCreateCertificateContext解析Base64格式证书时报“0x8009310b ASN1 遇到了不正确的标记值”
分析：
windows不支持Base64编码只支持Der编码
解决方案：
Base64证书先解码，然后使用
 
//使用根证书对用户证书进行验证，确认是自己颁发的
extern "C" int __stdcall VerifyUserCert(
char* CspName,
byte* UserCertInfo/*DER编码*/,
int nUserCertInfoSize,
byte* RootCertInfo/*DER编码*/,
int nRootCertInfo
)
{
int nRet = 0;
int nErrCode = 0;
PCCERT_CONTEXT pCertContextRoot = NULL;
 
//连接CSP
HCRYPTPROV hCryptProv = NULL;
if(!CryptAcquireContextA(
&hCryptProv,
NULL,
CspName,
PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT
))
{
nErrCode = GetLastError();
return 71;
}
//创建证书上下文
pCertContextRoot = CertCreateCertificateContext(X509_ASN_ENCODING, RootCertInfo, nRootCertInfo);
if (pCertContextRoot == NULL)
{ 
nErrCode = GetLastError();//0x8009310b 应该是证书的编码错了，不支持Base64编码只支持Der编码
return 92;//92 创建证书上下文失败
}
 
//使用根公钥对用户证书验签
if (!CryptVerifyCertificateSignature(
hCryptProv,
X509_ASN_ENCODING,
UserCertInfo,
nUserCertInfoSize,
&(pCertContextRoot->pCertInfo->SubjectPublicKeyInfo)))  //CA证书公钥
{
nErrCode = GetLastError();
return 93;//93 验证证书签名失败
}
 
return 0;
}

网上的解决办法要么是针对SP2，打补丁。
要么禁止IEEE 802.1X验证。
 
但也有很多人，像我一样用SP3,且上述验证是灰色。在网上搜索很久未果，今天终于在高手帮助下解决了，过程发出来，希望能帮助到有同样问题的朋友。
 

无线网络属性
 
无线网络配置
 
选择要连接的网络，属性
 
验证
 
EAP类型 （受保护的EAP），属性
 
受信任的根证书颁发机构（GTE CyberTrust Global Root），选择身份验证方法，属性，不自动选择登录名和密码
 
确定。
 
转自：http://blog.sina.com.cn/s/blog_54424ba30101p2hj.html

转载于:https://www.cnblogs.com/fjfhxotfl/p/4260820.html

    刚才用Dell笔记本WiFi上网的时候，突然网页打不开，找不到无线路由。重启路由后，系统托盘弹出气泡显示“Windows找不到证书来让您登陆到**网络”的提示，网络状态总是显示“正在验证身份”。马上转到邻居家的网络上，上网搜了一下，原来是加密验证问题。解决方法如下：
第一步，鼠标右键点击“网上邻居”选“属性”。
第二步，右键点击“无线网络连接”选“属性”。
第三步，点击“无线网络配置”在首选网络中选择要连接的网络，点击“属性”。
第四步，点击“验证”标签页，将“起用此网络的IEEE 802.1x验证”前的勾取消，按确定。
    最终的我并不是用这个方法解决的，王道的方法是升级笔记本的无线驱动程序，并且成功了。

这是上一个项目中发现的一个奇怪问题：
BS系统，客户端环境Windows XP + IE6，客户端使用证书验证。
我们制作的证书在几种常见的Windows版本和IE版本(6-8)进行了测试，都没有问题，可是到了用户环境，只要允许要求证书，响应就无应答。
我们使用了许多方式：
变换证书制作方式、使用SSH工具进行证书制作、分析IIS Log进行调查分析…………总之能想的都想了；
请教了各方联系到的证书方面的高人；
而且联络了微软工程师，从证书工程师到IIS工程师，通过在线支持等。。
总之，没有结果。
 
 
因为保密性，客户的环境我们不能带出公司，只得在他们内部进行最后的一搏：
1、验证了他们内部有个别人的机器证书使用正常（哈哈，网管）；
2、注意到了他们的环境上安装了Landesk（是不他们的网管修改了Landesk对他们机器的控制规则？^_@）？；
3、恩，有门~
 
 
这下确定了就是机器环境差异所致，花了半天进行了如下验证：

1、准备一台测试机，使用Ghost方式重建了一个空的Windows XP(sp3)环境，IE版本：IE6SP3(6.0.2900.5512.xpsp.080413-2111)；
    测试结果：OK;
2、加入客户域，使用一个有问题客户的域帐号登录；
    测试结果：OK;
3、设置IE的代理服务器与TMCI相同；
    测试结果：OK;
4、IE安全/本地Intranet/自定义安全级别/其他/没有证书或只有一个证书时不提示进行客户端选择：启用；
    测试结果：OK;
5、导入XX系统客户端证书；
    测试结果：OK;
6、安装Landesk；
    测试结果：OK;
7、运行Landesk打补丁程序（安装了160个补丁包，主要为微软各种补丁）；
    测试结果：NG；

 
问题出在第7步，原来是Landesk自动同步的哪个（些）补丁包有问题，经过排查，确定为KB977377的问题；有同事提醒：“遇到过此补丁会影响SSL协议传输”，且网上有类似“Win2003可选系统补丁导致公司内部SSL站点无法访问”的话题。
 
 
问题解决，对方领导抽烟时向我竖起了大拇指！
 
糗了贵公司的网管了，不好意思啊（我不是故意的，并且啥都没说@_@~）！
 
希望这个问题不要再遗害他人，志之，艰苦的一周！！！