Overview Windows Communication Foundation (WCF) is a unified programming model provided by Microsoft for building service-oriented applications (excerpted from MSDN). Security issues in a distributed environment are particularly important. If you feel that using WCF's default security measures can make You can sit back and relax, then you can go home and farm tomorrow. Of course, it is enough for learning~, but we are talking about real project applications. The security provision and guarantee of WCF under various protocols are not the same. of. X509 certificate introduction X.509 is a digital certificate standard formulated by the International Telecommunication Union (ITU-T). I believe this is well known. Currently, there are three versions of X.509 certificates as far as I know, the ones used in .net Yes x.509-2, version X.509-2 introduced the concept of subject and issuer unique identifiers to solve the problem that subject and/or issuer names may be reused after a period of time, x509-2 (hereinafter referred to as x509) certificate consists of two keys, usually called a key pair, the public key is encrypted and the private key is decrypted. Today I want to give an in-depth introduction and understanding of x509 here, because in the security system of WCF, the application of x509 certificate is very frequent, or it is indispensable. 1. How to generate a certificate? Use the Makecert.exe test certificate generation tool provided by Microsoft
It can help us get a x509 standard certificate. The specific method is as follows: Download Makecert.exe or locate your computer directory: C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin, look for it and see it Now, I strongly recommend that you copy Makecert.exe to a separate directory, such as D:\\cers.
Now click on the start menu - run - enter cmd, run the console application, navigate to D:\\cers, enter in the console: makecert -r -pe -$ individual -n "CN=mailSecurity" -sky exchange -sr currentuser -ss my mailSecurity.cer, you can generate an x509 certificate named mailSecurityr in the personal area under the current user certificate storage area, and output the certificate file mailSecurity.cer in the current directory. The following briefly introduces the meaning of various parameters. For more complex parameters, please refer to: Certificate Creation Tool Help
--------------------------------------- -------------------------------------------------- ---- The
name of the makecert certificate tool
-r indicates that the certificate to be generated is self-signed, and you will give yourself an award (here mainly refers to the issuing authority)
-pe indicates that the generated private key is marked as exportable. This allows the private key to be included in the certificate
- $ whether the certificate is personal or commercial (individual/commercial).
-n means the subject of the certificate, you just treat it as the title, no matter what name you choose, it must contain the CN= prefix
-sky specifies the key type of the subject, which must be signature, exchange or an integer representing the provider type. By default, you can pass in 1 for exchange keys and 2 for signing keys
-sr Specifies the subject's certificate storage location. Location can be currentuser (default) or localmachine (actually it must be one of these two values)
-ss specifies the name of the subject's certificate store, where the output certificate is stored
mailSecurity.cer certificate name, does not have to be the same as the subject, but I suggest that you still do well.
-------------------------------------------------- --------------------------------------------
Via in the start menu - run - Enter mmc to select the certificate unit to view and manage the certificate. You can also manage the certificate through the certmgr.exe certificate management tool provided by Microsoft. It is in the same directory as makecert.exe. It is quite simple to use, just double-click it. Of course, you can also Running it through the command line mode is well reflected in many batch files of Microsoft. For details, see: Certificate Manager Tool
2. What secrets are contained in the certificate?
The first thing we must know is that the certificate generation tool provided by Microsoft provides us with two key algorithms (MD5/SHA1). We can specify it when generating the certificate. If it is not specified, the MD5 algorithm is used by default. But when I generate the certificate with SHA1 algorithm, strange things happen.
The public key encryption strength is: 1024
algorithm signature: sha1RSA
3、看到这里，我想我们都很想知道，为什么会这样？ 不是采用的SHA1算法吗？为什么算法签名为：sha1RSA？
看来，在这里不得不提到RSA算法提供程序，看看微软的官方说明：如果安装了 Microsoft Enhanced Cryptographic Provider，则 RSACryptoServiceProvider 支持长度从 384 位至 16384 位（增量为 8 位）的密钥。如果安装了 Microsoft Base Cryptographic Provider，则支持长度从 384 位至 512 位（增量为 8 位）的密钥。
本机肯定是安装了Microsoft Enhanced Cryptographic Provider的，因为我今天刚测试过了，用最长密钥长度生成密钥，时间可能你都不敢想，看图说话算了。
几近7分钟，长度16384位。
RSA加密过程：
4、从这里可以看出，我们证书所能生成的密钥长度还可以很长，当你使用SHA1算法生成证书时，makecert默认加密强度为1024位，加密后的内容长度为128位，很标准的，当然，你还可以用上面的代码测试其它长度，但请注意，每个长度增量为8位，如1024位，下一个长度为：1024+8＝1032,指定密钥长度必须符合增量规范。
5、证书存储位置选择
有朋友也许认为，证书存储位置一般不都是照搬微软的那一套嘛，其实不然，有以下几种情况是我们在真正的项目应用中不容忽视的。
1）开发模式：开发模式时，为方便我们一般都采用控制台作为WCF服务的宿主，意味着当前运行的帐户权限为当前账户，估计多半是管理员权限了，这个时候你是不用担心你的证书存储在哪里的，只要你的证书生成了就好，实际真的就是这么回事，当你将你的WCF安全配置更改一下，看代码了：
如果你的证书现在不受信任，如果你还过得了服务，你就牛X了。 证书authentication （服务器与客户端）共有四种：
None= 未执行任何证书验证
PeerTrust=如果证书位于被信任的人的存储区中，则有效
ChainTrust=如果该链在受信任的根存储区生成证书颁发机构，则证书有效
PeerOrChainTrust=如果证书位于被信任的人的存储区或该链在受信任的根存储区生成证书颁发机构，则证书有效
Custom=用户必须插入自定义 X509CertificateValidator 以验证证书(这种模式很有意思，后面会提到)
实际上，只要你把信任模式更改为：None，证书放在哪里都无所谓了。
2）部署模式
我强烈推荐以windows service作为WCF宿主，不论从效率或者安全及稳定性上来说，windows service都是最棒的，特别是你的WCF服务还是以TCP命名管道作为主要通信手段的时候，windows servcie就更值得你考虑了，先不要说IIS6.0不支持TCP协议先。
在以windows servcie方式运行WCF host的时候，你首先会碰上第一个问题，找不到证书，一般都会提示你，不能以下列搜索标准找到证书，该进程必须具有对私钥的访问权限，哥们，听我一句话，在这个时候，你就千万不要相信人云亦云的通过微软的FindPrivateKey工具找到证书文件，给LOCAL SERVICE访问权限，你不信去试试，问题依旧。
In fact, the reason for this problem is very funny, just because you always use the same certificate when developing, and only use one certificate when deploying for granted. If you use two certificates at the beginning, the client and server use The certificate is mutually authenticated and encrypted, so you should have no problem. The first one below is a very serious principle.
(1) With windows servcie as the WCF Host, if the message encryption strategy is adopted and X509 certificate security is enabled, the installation location of the X509 certificate must be LocalMachine, and the certificate should be located in the TrustedPeople location.
(2) This is only the most basic requirement, don't take it as a dogma. In fact, it is true that the certificate must be stored in LocalMacnine, but the location should be adjusted according to your <authentication certificateValidati/> strategy. If you put The certificate is placed in: ROOT (Trusted Root Certification Authority), you can put the certificate wherever you want, even in the My (personal) area.
(3) At the same time, you should also copy the client certificate to the trusted certificate authority area, the most basic thing, of course, this is still related to the security policy.
(4) The client and the server use certificates for mutual authentication, and asymmetric encryption is used in the true sense. Regarding the mutual authentication between the client and the service, I will talk about it next time. I think it is a bit long.
3) When you start the security policy,
keep in mind that the security policy determines your service security level, of course, the higher the better, as you saw just now, it took 7 minutes to generate a key , it's hard to bear~~, isn't it?