手机银行https证书有效性验证引发的安全问题
HTTPS如何实现前向安全性和身份验证
HTTPS如何实现前向安全性和身份验证在当今的互联网世界中，我们在网上进行各种活动，如购物、社交、银行交易等。
而这些活动的安全性至关重要，HTTPS 就是保障我们网络通信安全的重要手段之一。
那么，HTTPS 是如何实现前向安全性和身份验证的呢？让我们一起来深入了解一下。
首先，我们要明白什么是前向安全性和身份验证。
前向安全性指的是即使攻击者获取了当前的通信密钥，也无法解密过去的通信内容。
身份验证则是确保我们正在与之通信的服务器或网站是真实可靠的，而不是被恶意攻击者伪装或篡改的。
为了实现前向安全性，HTTPS 采用了一种叫做“短暂密钥交换”的机制。
简单来说，每次建立 HTTPS 连接时，客户端和服务器都会生成一对临时的密钥，用于本次通信的加密和解密。
这些临时密钥只在当前连接中有效，一旦连接结束，它们就会被丢弃。
这就好比我们每次去一个新的地方都要重新换一把临时的钥匙，即使之前的钥匙被别人偷走了，也不用担心他们能用它打开我们之前去过的地方的门。
那么，这些临时密钥是如何生成和交换的呢？这就要用到一些加密算法，比如 DiffieHellman 密钥交换算法。
在这个过程中，客户端和服务器通过交换一些公开的信息，然后各自根据这些信息计算出只有双方知道的共享密钥。
这个共享密钥就是我们前面说的临时密钥。
而且，为了进一步增强安全性，这些临时密钥的生成还会考虑到一些随机因素，比如当前的时间、网络环境等，使得每次生成的密钥都是独一无二的，难以被预测和破解。
接下来，我们再看看 HTTPS 是如何进行身份验证的。
这主要通过数字证书来实现。
当我们访问一个使用 HTTPS 的网站时，服务器会向我们的客户端发送一个数字证书。
这个数字证书就像是服务器的“身份证”，里面包含了服务器的一些重要信息，比如服务器的名称、域名、公钥等，同时还有一个数字签名。
数字签名是由权威的证书颁发机构（CA）使用其私钥对证书中的信息进行加密生成的。
当我们的客户端收到数字证书后，会使用证书颁发机构的公钥来验证数字签名的有效性。
网上银行证书下载
网上银行证书下载随着网络技术的发展和普及，网上银行成为了我们日常生活中不可或缺的一部分。
作为一种方便快捷的金融服务方式，网上银行为我们提供了便捷、安全的金融服务。
但是，在使用网上银行时，验证网站的真实性是非常重要的。
而证书的下载则是验证网站真实性的关键一步。
本文将会探讨网上银行证书的下载过程，并给出一些使用注意事项。
一、什么是网上银行证书？网上银行证书，即数字证书，是一种通过公钥加密技术认证网上银行网站真实性的文件。
它由经过权威认证的第三方机构（如CA机构）颁发给网上银行，用于保障用户在网上银行上的交易安全。
通过验证证书的有效性，用户可以确认网站的真实性，确保自己的信息在传输过程中不被窃取或篡改。
二、下载网上银行证书的步骤1. 打开浏览器，在地址栏输入网上银行的网址并按下回车键。
2. 在登录页面中，检查浏览器地址栏的网站域名是否正确。
正确的网址通常以https://开头，并在地址栏前显示一个锁形状的标志。
3. 点击地址栏左侧的锁形状标志，在下拉菜单中选择“证书详情”。
4. 在弹出的证书详情窗口中，点击“安装证书”按钮。
根据浏览器的提示，完成证书的下载和安装过程。
三、网上银行证书下载的注意事项1. 确认证书的合法性：在下载证书之前，应该先核实网上银行的真实性，确保证书是由合法的第三方机构颁发的。
可以通过查阅官方渠道的公告或咨询银行客服等方式确认证书的真实性。
2. 保持浏览器的安全设置：使用网上银行时，应该保持浏览器的安全设置开启状态，以确保证书的有效性。
可以在浏览器的设置中检查和调整安全级别。
3. 定期更新证书：证书通常有一定的有效期限，过期的证书可能会带来安全隐患。
应该定期检查证书的有效期限，如果证书即将过期，及时下载更新。
4. 注意安全警示：在下载证书的过程中，应该留意浏览器的安全警示信息。
如果浏览器显示关于网站的不安全警告或证书信任问题的警示，应该停止下载并与银行联系。
本文介绍了网上银行证书的下载步骤和注意事项。
自签名的https证书是不安全的
⾃签名的https证书是不安全的⼀、项⽬内的需求我们做的app都是企业级的应⽤，⽽企业级的应⽤的下载需要遵循itms协议，itms协议下需要https链接，这就需要你的服务器⽀持https的协议，该协议需要申请SSL证书，我们测试时⽤的是⾃签名的证书，⽽⾃签名的证书本来就就存在不安全⾏，⾃从ios10.3更新以来即使安装了⾃签名的证书也报错，说⽆法下载app,是因为苹果阻⽌了不受信任的证书⼆、解决⽅案1、⾃签名的证书，需要⼿动的为证书打开信任，通⽤->关于本机->证书信任设置->证书打开信任2、申请可信任的证书像StartCom的证书，当然会很贵，关于ios中可⽤的受信任的根证书列表，可以参考苹果的官⽅的⽂档三、⾃签名的证书为什么是不安全的1、⾃签证书最容易受到SSL中间⼈攻击⾃签证书是不会被浏览器所信任的证书，⽤户在访问⾃签证书时，浏览器会警告⽤户此证书不受信任，需要⼈⼯确认是否信任此证书。
所有使⽤⾃签证书的⽹站都明确地告诉⽤户出现这种情况，⽤户必须点信任并继续浏览！这就给中间⼈攻击造成了可之机。
2、⾃签证书⽀持不安全的SSL通信重新协商机制⼏乎所有使⽤⾃签SSL证书的服务器都存在不安全的SSL通信重新协商安全漏洞，这是SSL协议的安全漏洞，由于⾃签证书系统并没有跟踪最新的技术⽽没有及时补漏！此漏洞会被⿊客利⽤⽽截获⽤户的加密信息，如银⾏账户和密码等，⾮常危险，⼀定要及时修补。
3、⾃签证书使⽤不安全的1024位⾮对称密钥对⽽⽬前⼏乎所有⾃签证书都是1024位，⾃签根证书也都是1024位，当然都是不安全的。
还是那句话：由于部署⾃签SSL证书⽽⽆法获得专业SSL证书提供商的专业指导，根本就不知道1024位已经不安全了4、⾃签证书证书有效期太长⾃签证书中还有⼀个普遍的问题是证书有效期太长，短则5年，长则20年、30年的都有，并且还都是使⽤不安全1024位加密算法。
可能是⾃签证书制作时反正⼜不要钱，就多发⼏年吧，⽽根本不知道PKI技术标准中为何要限制证书有效期的基本原理是：有效期越长，就越有可能被⿊客破解，因为他有⾜够长的时间(20年)来破解你的加密。
HTTPS协议在网络安全中的重要性
HTTPS协议在网络安全中的重要性在当今科技高度发达的时代，互联网已经成为我们生活中不可或缺的一部分。
每天我们都会在网络上进行各种各样的活动，如网上购物、社交媒体互动、在线银行交易等。
然而，这种便捷的网络体验也带来了一些安全隐患。
为了确保我们在互联网上的数据传输安全，HTTPS协议应运而生，并在网络安全中发挥着至关重要的作用。
一、HTTPS协议的基本原理HTTPS协议是一种用于安全数据传输的网络协议，全称为"Hypertext Transfer Protocol Secure"。
它基于HTTP协议，在传输层使用SSL或TLS协议进行加密，以保证数据在传输过程中的安全性。
HTTPS的工作原理如下：首先，客户端向服务器发起HTTPS连接请求，服务器则将自己的数字证书发送给客户端。
客户端会验证证书的合法性，确保连接的真实性和数据的完整性。
接下来，客户端生成一个用于对称加密的密钥，然后使用服务器的公钥对密钥进行加密并发送给服务器。
服务器接收到加密后的密钥后，再用私钥进行解密，得到对称加密的密钥。
双方之间的通信将使用这个共享密钥进行加密和解密，从而确保数据在传输过程中的安全性。
二、1. 数据传输的机密性：HTTPS协议通过使用SSL/TLS协议对数据进行加密，使得第三方无法直接获取到传输的数据内容。
这样即使黑客窃取了数据，也无法解密其中的信息，有效保护了用户隐私。
2. 数据的完整性保证：HTTPS协议还使用了数字证书，通过对发送和接收数据进行数字签名，确保数据的完整性。
这样，接收方可以验证数字签名的有效性，以确定数据是否被篡改过。
3. 身份验证的可靠性：HTTPS协议使用数字证书对服务器进行身份验证，确保用户的连接是与合法的服务器建立起来的。
这样可以有效防止中间人攻击等恶意行为。
4. 提供更好的用户体验：HTTPS协议在保障数据安全的同时，还可以提供更好的用户体验，例如加快网页加载速度、增强搜索引擎优化等。
HTTPS如何防范网络嗅探和流量分析攻击
HTTPS如何防范网络嗅探和流量分析攻击在当今数字化的时代，网络安全成为了至关重要的问题。
网络嗅探和流量分析攻击是常见的威胁手段，它们可能导致用户的隐私泄露、数据被窃取以及系统受到恶意干扰。
而 HTTPS 作为一种安全的通信协议，在防范这类攻击方面发挥着关键作用。
首先，让我们来了解一下什么是网络嗅探和流量分析攻击。
网络嗅探指的是通过监听网络中的数据包，获取其中的敏感信息，比如用户名、密码、信用卡号等。
流量分析攻击则是对网络中的数据流量进行分析，以推断出用户的行为、访问的网站、使用的服务等信息。
这两种攻击手段都具有隐蔽性和危害性，给用户和企业带来了巨大的风险。
HTTPS 之所以能够有效地防范网络嗅探和流量分析攻击，主要基于以下几个方面的特性。
其一，加密机制。
HTTPS 使用了加密技术来保护数据的传输。
在HTTPS 连接中，数据在发送之前会被加密，只有在接收端才能被解密。
这意味着即使攻击者成功地嗅探到了数据包，他们看到的也只是一堆无法理解的乱码。
常见的加密算法如 AES 等，为数据提供了高强度的加密保护，使得攻击者难以从中获取有价值的信息。
其二，身份验证。
HTTPS 还通过数字证书来验证服务器的身份。
当用户与服务器建立连接时，服务器会向用户发送其数字证书。
用户的浏览器会对证书进行验证，确保其来自可信的来源。
如果证书存在问题或者无法通过验证，浏览器会发出警告，提醒用户可能存在风险。
这种身份验证机制有效地防止了攻击者伪装成合法的服务器，从而避免用户向恶意服务器发送敏感信息。
其三，完整性保护。
除了加密和身份验证，HTTPS 还确保数据在传输过程中的完整性。
通过使用消息认证码（MAC）等技术，接收方可以验证接收到的数据是否在传输过程中被篡改。
如果数据的完整性受到破坏，接收方可以立即发现并拒绝接收。
在实际应用中，HTTPS 的部署也需要注意一些问题。
首先，证书的管理至关重要。
服务器需要确保其数字证书的有效性和安全性，定期更新证书，以防止证书被吊销或过期导致的连接问题。
https 网络安全
https 网络安全随着互联网的快速发展，网络安全问题也日益突出，特别是在数据传输和信息交流方面，保障用户的隐私和数据安全变得越来越重要。
为了解决这些问题，HTTPS（Hypertext Transfer Protocol Secure）应运而生，它是一种通过加密和身份认证来保护网络传输安全的协议。
HTTPS的主要特点就是通过SSL（Secure Sockets Layer）或TLS（Transport Layer Security）协议来加密传输数据，确保用户与服务器之间的通信是私密且安全的。
使用HTTPS协议，可以有效防止网络拦截、黑客攻击以及信息泄露等安全风险。
首先，HTTPS通过传输层加密（TLS/SSL）技术，使得数据在传输过程中被加密，确保数据的完整性和保密性。
传输过程中的数据经过加密算法处理，使得黑客无法轻易窃取和篡改用户的信息。
这种加密技术是目前最常见和可靠的方式，广泛应用于网上银行、电子商务等需要保护用户隐私和交易安全的场景。
其次，HTTPS通过服务器证书实现身份认证，确保用户访问的是真实可信的网站。
HTTPS采用公钥加密和私钥解密的方式，网站服务器通过数字证书向用户证明自己的身份，并提供公钥给用户。
用户通过验证数字证书，确认网站的真实性和可信度，进而建立起安全的通信连接。
这样，用户在进行在线交易、输入个人信息等操作时，可以更加放心和安全。
此外，HTTPS还可以防止网络攻击，提高网络安全性。
因为HTTPS采用加密传输，黑客无法通过网络嗅探、数据篡改等方式获得用户的隐私信息。
同时，HTTPS还具有域名锁定、数据验证等安全措施，有效预防中间人攻击和欺骗等网络安全问题。
相比起HTTP协议，HTTPS是更好的选择，可以降低用户被攻击和受损的风险。
然而，值得注意的是，虽然HTTPS可以有效提升网络安全性，但并不代表绝对安全。
恶意软件、社会工程学等方式仍然存在安全隐患。
因此，用户在使用HTTPS的同时，也要提高安全意识，警惕各种网络攻击，保护好自己的个人信息。
银行业面临的信息安全问题及整改对策
银行业面临的信息安全问题及整改对策一、引言如今，随着数字化时代的到来，信息技术已经在各个领域得到广泛应用，银行业也不例外。
然而，在享受数字化带来的便利与高效的同时，银行面临的信息安全问题也日益凸显。
本文将就银行业面临的信息安全问题进行分析，并提出相应的整改对策。
二、银行业面临的信息安全问题1. 数据泄露和盗窃由于银行业具有庞大的客户数据量和金融交易数据，这些数据往往成为黑客攻击和内部人员不当使用的目标。
一旦发生数据泄露或盗窃，客户敏感信息暴露风险极大。
2. 恶意软件和网络攻击恶意软件和网络攻击针对银行系统进行入侵和破坏已成为常态。
例如，网络钓鱼、勒索软件和僵尸网络等形式不断涌现，给银行信息系统带来巨大威胁。
3. 内部操作风险内部操作失误、疏忽或者恶意行为可能导致敏感信息的泄露和金融交易风险的增加。
员工在使用电子设备时的安全意识和行为习惯在很大程度上决定着银行信息系统的整体安全。
4. 第三方合作伙伴安全风险银行业与很多第三方机构合作，如支付机构、外包服务商等。
这些合作伙伴可能存在安全措施不足或者恶意操作，从而带来潜在的信息安全风险。
5. 法规合规问题随着金融监管政策和法律法规的日益完善，诸如个人信息保护、反洗钱等合规要求不断提高。
银行业必须确保自身遵守相关法律法规，否则将面临处罚和经营风险。
三、整改对策针对上述问题，银行业应采取以下整改对策来提升信息安全水平：1. 提升技术防护能力建立健全的信息系统保护体系是保障信息安全的关键。
银行应注重技术投入，引入最新的防护技术和设备来减少数据泄露和网络攻击风险。
此外，银行还应积极进行网络安全演练，提高系统运维人员的技术水平。
2. 加强内部安全管理银行业必须制定严格的安全政策和规范，确保员工了解并严格遵守。
此外，定期对员工进行信息安全培训，并建立完善的数据访问权限控制机制，将敏感数据与金融交易数据做好分类存储和加密保护。
3. 加强合作伙伴管理与第三方机构合作时，银行应建立起有效的合作伙伴选择和监督机制。
浅析电子银行存在的主要风险及我行电子银行部对风险的防范措施
浅析电子银行存在的主要风险及我行电子银行部对风险的防范措施一、电子银行概述（一）电子银行的发展电子银行是伴随计算机与互联网技术发展，由金融创新带来的产物，是以互联网为渠道，为客户提供多种金融服务的银行，其不仅仅是银行业务的电子化，也包括对银行业务活动和流程的改造，使信息技术发挥其在降低经营成本，提高管理效率和质量等方面的作用，当前的电子银行的业务主要包括利用计算机和互联网开展的网上银行业务，利用电话等声讯设备和电信网络开展的电话银行业务，利用移动电话和无线网络开展的手机银行业务，以及其他利用电子服务设备和网络，由客户通过自助服务方式完成金融交易的业务，如自助终端、ATM、POS等。
电子银行业的发展一般会经历了三个阶段。
在实体银行阶段,银行有经营业务的营业场所和人员,办理业务是面对面的,业务处理主要以手工为主,兼以部分电子化;在电子银行阶段,经营实体仍然存在,但电子化应用程度大大提高,银行业务辅以电话银行、无人自助银行等形式,自动柜员机、自动存款机、自动发卡机、夜间金库等电子金融产品的出现,极大地方便了银行客户;虚拟银行阶段是银行发展的较高层次,在这个阶段中,银行经营实体将不复存在,业务交易主要是通过计算机网络的运行来实现。
网上银行是该阶段发展过程中的典型代表。
（二）电子银行的特点网上银行又被称为“3A银行”，因为它不受时间、空间限制，能够在任何时间(Anytime)、任何地点(Anywhere)、以任何方式(Anyhow)为客户提供金融服务，随着经济与社会的不断进步，居民对金融服务的需求呈现多样化的趋势。
如何满足居民日益多样化的金融需求是各大金融机构追求的目标，电子银行的发展呈现以下特点：1、安全可靠：以我行为例，我行电子银行业务在网络安全上采用了防黑客技术，设置了二代交易按键Ukey，为用户设置了Ukey密码、登陆密码、交易密码、登陆名称等多种安全措施，客户在使用网上银行办理业务时能够看得见的防范措施有客户证书及其密码。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
手机银行https证书有效性验证引发的安全问题前言：在实际项目代码审计中发现，目前很多手机银行虽然使用了https通信方式，但是只是简单的调用而已，并未对SSL证书有效性做验证。
在攻击者看来，这种漏洞让https形同虚设，可以轻易获取手机用户的明文通信信息。
手机银行开发人员在开发过程中为了解决ssl证书报错的问题（使用了自己生成了证书后，客户端发现证书无法与系统可信根CA形成信任链，出现了CertificateException等异常。
），会在客户端代码中信任客户端中所有证书的方式：?1 2 3 4 5 6 7 8 91011121314151617181920212223242526272829 public static HttpClient getWapHttpClient() {try {KeyStore trustStore = KeyStore.getInstance(KeyStore.g trustStore.load(null, null);SSLSocketFactory sf = new MySSLSocketFactory(trustSto sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOS //此处信任手机中的所有证书，包括用户安装的第三方证书HttpParams params = new BasicHttpParams();HttpProtocolParams.setVersion(params, HttpVersion.HTT HttpProtocolParams.setContentCharset(params, HTTP.UTF SchemeRegistry registry = new SchemeRegistry();registry.register(new Scheme(“http”, PlainSocketFacregistry.register(new Scheme(“https”, sf, 443));ClientConnectionManager ccm = new ThreadSafeClientCon303132333435363738return new DefaultHttpClient(ccm, params); } catch (Exception e) {return new DefaultHttpClient();}}而在客户端中覆盖google默认的证书检查机制（X509TrustManager），并且在代码中无任何校验SSL证书有效性相关代码：?1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031 public class MySSLSocketFactory extends SSLSocketFactory {SSLContext sslContext = SSLContext.getInstance(“TLS”);public MySSLSocketFactory(KeyStore truststore) throws NoSuchAlgorit super(truststore);TrustManager tm = new X509TrustManager() {public void checkClientTrusted(X509Certificate[] cha }//客户端并未对SSL证书的有效性进行校验，并且使用了自定义方法的方式覆盖 public void checkServerTrusted(X509Certificate[] chai }public X509Certificate[] getAcceptedIssuers() {return null;}};sslContext.init(null, new TrustManager[] { tm }, null);}问题出来了：如果用户手机中安装了一个恶意证书，那么就可以通过中间人攻击的方式进行窃听用户通信以及修改request或者response中的数据。
手机银行中间人攻击过程：1 客户端在启动时，传输数据之前需要客户端与服务端之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。
2 中间人在此过程中将客户端请求服务器的握手信息拦截后，模拟客户端请求给服务器（将自己支持的一套加密规则发送给服务器），服务器会从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给客户端。
证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
3 而此时中间人会拦截下服务端返回给客户端的证书信息，并替换成自己的证书信息。
4 客户端得到中间人的response后，会选择以中间人的证书进行加密数据传输。
5 中间人在得到客户端的请求数据后，以自己的证书进行解密。
6 在经过窃听或者是修改请求数据后，再模拟客户端加密请求数据传给服务端。
就此完成整个中间人攻击的过程。
以fiddler工具模拟中间人攻击为例：1 首先在手机中装入fiddler根证书：导出fiddler的根证书：将fiddler根证书放入手机的SD卡中，然后在手机设置-安全中选择从SD卡中安装证书：成功安装fiddler根证书到手机上：2 在PC端打开fiddler，将手机通信代理到PC端fiddler所监听的端口上（可以在wifi中的高级设置中设置代理），这样手机银行的所有通信均会被fiddler 监听到。
3 启动手机银行客户端，会在fiddler中查看到所有请求的明文数据，并且可以进行修改后转发，成功将https加密绕过。
防护办法：使用CA机构颁发证书的方式可行，但是如果与实际情况相结合来看的话，时间和成本太高，所以目前很少有用此办法来做。
由于手机银行服务器其实是固定的，所以证书也是固定的，可以使用“证书或公钥锁定”的办法来防护证书有效性未作验证的问题。
具体实现：1 公钥锁定将证书公钥写入客户端apk 中，https 通信时检查服务端传输时证书公钥与apk 中是否一致。
?1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 public final class PubKeyManager implements X509TrustManager{private static S +”0105000382010f003082010a028*******b35ea8adaf4cb6db86068a836f3c85″ +”5a54+”ac1a9116acc883862f00593199df19ce027c8eaaae8e3121f7f329219464e657″ +”2cbf +”609851849dd6214589a2ceba4f7a7dcceb7ab2a6b60c27c69317bd7ab2135f50″ +”c631“33238c858ad179a82459c4718019c111b4ef7be53e5972e06ca68a112406da38″ +“cf60d2f4fda4d1cd52f1da9fd6104d91a34455cd7b328b02525320a35253147b” +“e0b7a5bc860966dc84f10d723ce7eed5430203010001″;//锁定证书公钥在apk 中public void checkServerTrusted(X509Certificate[] chain, String authType) thro{if (chain == null) {throw new IllegalArgumentException(“checkServerTrusted: X509Certificate arra}if (!(chain.length > 0)) {throw new IllegalArgumentException(“checkServerTrusted: X509Certificate is e}if (!(null != authType && authType.equalsIgnoreCase(“RSA”))) {throw new CertificateException(“checkServerTrusted: AuthType is not RSA”);}// Perform customary SSL/TLS checkstry {41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 TrustManagerFactory tmf = TrustManagerFactory.getInstance(“X509″);tmf.init((KeyStore) null);for (TrustManager trustManager : tmf.getTrustManagers()) {((X509TrustManager) trustManager).checkServerTrusted(chain, authType);}} catch (Exception e) {throw new CertificateException(e);}// Hack ahead: BigInteger and toString(). We know a DER encoded Public Key be// with 0×30 (ASN.1 SEQUENCE and CONSTRUCTED), so there is no leading 0×00RSAPublicKey pubkey = (RSAPublicKey) chain[0].getPublicKey();String encoded = new BigInteger(1 /* positive */, pubkey.getEncoded()).toStri// Pin it!final boolean expected = PUB_KEY.equalsIgnoreCase(encoded);if (!expected) {throw new CertificateException(“checkServerTrusted: Expected public key: ”+ PUB_KEY + “, got public key:” + encoded);}}}}2 证书锁定：即为客户端颁发公钥证书存放在手机客户端中，在https通信时，在客户端代码中固定去取证书信息，不是从服务端中获取。