First, the validation of digital certificates in three main areas:
(1) a digital certificate validity verification
(2) root certificate validation
(3) CRL validation
1, the digital certificate validity verification
means that the certificate in the time to start and end times within. It is easy to get a certificate by parsing the certificate is valid
2, the root certificate to verify
first understand what is the root certificate?
Ordinary certificates generally consists of three parts: user information, user's public key, and CA signature
so we have to verify that this certificate is required to verify the authenticity of the CA signature. Then we need CA public key. And in addition there is a public CA certificate (this certificate is called ordinary certificates signed certificate) in. So we need to verify the authenticity of a certificate of another. In addition it is also required to verify another certificate (called this certificate is a certificate signed by another certificate) authenticity. Turn back down, get a certificate chain. Then this certificate chain from where it end? That is, the end of the root certificate (root certificate to verify that that is the end). Root certificate is a very special certificate, which is the center of ourselves CA-signed certificate (ie, this certificate is to be signed this certificate with a CA public key). Trust this certificate on behalf of the trust certificate chain in this certificate.
All users must first download the root certificate before you use your own certificate.
The so-called root certificate to verify that: a root certificate public key to verify the signature of the certificate issuer. So first of all must have a root certificate and root certificate must be in the list of trusted certificates (that is, the trusted domain).
3, CRL verification
CRL is a CA-signed certificate through the void list for freezing and certificate revocation. Generally there CRL certificate address for access HTTP or LDAP, CRL obtained by parsing the address, and then download the CRL validation.
There certificate and CRL effective date and the date of the next update, so the CRL is updated automatically, so there will be delayed.
So then, there is another way OSCP certificate status online query, you can query real-time certificate status.
Comparison of two certificate status query:
Two, HTTPS certificate validation security problems caused by
If a malicious user phone certificate is installed, the user may eavesdrop and modify communication request (request) or data (reply response) in response by way of the middle attack.
Mobile banking middle attacks procedure:
1, when the client starts, a handshake between the client and the server needs before transmitting data, establish password information encrypted transmission of data both in the handshake process.
2, after the handshake intermediary client requests to the server during this process interception, analog client requests to the server (to send its own set of support encryption rules to the server) , the server will be selected from a set of cryptographic algorithm and HASH algorithm and their identity information in the form of a certificate sent back to the client. Certificate which contains the website address, public key encryption, as well as the certificate authority information.
3, but this time under the intermediary intercepts returned from the server certificate information to the client, and to replace their certificate information.
4, the client response obtained middleman broker will choose a certificate encrypted data transmission.
5, the intermediary data after obtaining the client request to decrypt own certificate.
6, after eavesdropping or modification request data, and then the analog data to the requesting client server encrypted. This completes the entire process middleman attack.
Fiddler tool to simulate middle attacks, for example:
1, was initially charged with fiddler root certificate in your phone:
Export fiddler root certificate; the fiddler root certificates in the phone's SD card, and then in the phone settings - security, select Install Certificate from the SD card; fiddler successfully installed the root certificate to your phone.
2, open the fiddler on the PC side, the mobile communications agent to the port on the PC side fiddler is listening (set up agents in the Advanced Settings wifi in the middle), all such communications will be mobile banking fiddler listening to.
3, start mobile banking clients will see in fiddler in all the requested data to plain text, and can be modified to forward, success will https encryption bypassed.
Protective measures:
Using CA certificate issued by the agency way possible, but if combined with the actual situation, then, the time and cost is too high, so now rarely useful way to do this. Since mobile banking server is actually fixed, so the certificate is fixed, you can use the "certificate or public key lock" approach to protection certificate validity issues have not been verified.
Implementation:
1 Public Key Lock
The public key certificate apk written to the client, the public key certificate is consistent with the apk in check when the service ended transmission https communications.
2 certificate Lock:
The client is the public key certificate issued by the client is stored in the phone, when https communication, the client code fix to get the certificate information, not from the server.
Third, the root certificate
1. Definitions
CA root certificate is a core institution that issued the SSL certificate is the starting point of the chain of trust. Root certificate is whether the browser for SSL certificate for each browser has a root certificate store, and some browser are using their own root certificate store, and some third-party browsers are taking root certificate store. The root certificate store is preloaded with root certificates when you download the client browser collection. Therefore, the root certificate is very important because it ensures that the browser automatically trust has been signed with the private key SSL certificate. Trusted Root Certificate Authority certificate belongs (CA), while CA is to verify and institutions issuing organization SSL certificate.
2. What is a certificate chain?
How to identify browser is SSL certificate trusted sites? In fact, when the Client Access server, the browser will check the authenticity of SSL certificates and perform quick validation SSL certificate.
Browser Identification SSL certificate authentication operation is based on the contents of the certificate chain. So what's certificate chain?
User before obtaining an SSL certificate, you must first generate a certificate signing request (CSR) and private key. In the simplest iteration, user-generated CSR will happen to the certification authority, and then use the root CA certificate signed by the user's private key institutions of SSL certificates and SSL certificate is sent back to the user.
When a browser detects SSL certificate, which will see the certificate is issued by a trusted root certificate signature (the signature using the private key of the root). Because the browser trust root, so the browser can also trust any certificate signed root certificate.
The certificate chain is composed of two aspects of the composition - trust anchor (CA certificate) signed certificate links and links . Trust anchor CA certificate link may sign intermediate certificate; intermediate certificate owner can use their private key to another certificate signature. This combination of the two would constitute a certificate chain.
3. What is an intermediate certificate?
Certificate Authority (CA) will not be issued directly from the root directory of the server certificate (SSL certificate that is), because such behavior is very dangerous, because once an error or need to revoke root issue occurs, the use of each certificate will be signed root revocation of trust.
Therefore, in order to avoid this risk, CA agency usually cited among the root. CA agency uses its private key to sign the intermediate root, the browser trust among roots. Then use the CA private key intermediate root certificate to sign the SSL certificate user application. This intermediate form may be repeated a plurality of times the root, i.e., the use of another intermediate middleware root sign, then the SSL certificate signed by a CA middleware.
This is the certificate chain of the visualization process can be seen from the above examples, CA mechanism requires only a simple operation to maintain the intermediate, but in fact the real certificate chains are generally much more complex.
4, digital signatures What is the role?
When the root certificate signed by the intermediate certificate in digital form, it will be transferred to the middle part of the trust certificate. Because the signature is directly derived from the private key of the root certificate recipient , it will be automatically trusted.
When SSL Certificates browser or other client detects the server, you will receive a certificate with a public key certificate itself or associated. Then the public key, unlock the digital signature, see the certificate is signed by the Which companies. That is when a client browser to access the website, SSL certificate server will authenticate the user, the public key to unlock an encrypted signature, the signature will be unlocked with a certificate signed by the browser back to the trusted root certificate store in.
If unlocked signature links are not in the browser trusted root certificate store, the browser will display the certificate unsafe.
5, the root CA certificate and intermediate root CA difference?
Root CA certificate is to have one or more trusted root certification authority, that agency has taken root CA in the trust library main browser. The intermediate root CA or sub-CA certificates are issued by the middle of the root certification authority, they do not necessarily have a root certificate in the browser trust store, but their roots intermediate link recovery to a trusted third-party root, this would It is called cross-signature.
So there are a number of CA certificate issued by the agency is not directly emitted from their roots, but rather to enhance the security level by the middle of the root signing certificate, which helps reduce the chance of error or safety incidents. If the revocation of intermediate root, rather than the root certificate and certificate revocation signed by extension, this approach will lead to a certificate issued by an untrusted root middle.
In fact, currently there is a classic case, is Google and other mainstream browsers canceled SSL certificates Symantec brand. It is reported that Symantec SSL certificate has been issued millions, cancel their confidence seems to be a daunting project. In practice, however, this is a very simple task, since only need to remove all the roots Symantec CA's root certificate store of the browser can be.
6, the difference between the chain and root single root?
Single root CA is owned, directly issue a certificate allowing the procedure to deploy certificates easier. The chain is the root content Sub CA for issuing certificates, is an intermediate certificate, but since the middle of the root CA certificate is not trusted himself, it must be linked to a trusted third party CA.
Differences as follows:
Root chain requires more complex method of installation , the root since the intermediate and the need to be loaded into each server hosting the application certificate. Chain root required by the CA dominated links , because they can not control the root user, once the root CA of business, they will receive tremendous implications. Root and intermediate certificates expire , then the middle root root certificate must be in before , this will increase the difficulty of the work .
Finally, the above mentioned certificate issued by a trusted root certificate authority, certificate chain signatures and encryption, in fact, are essentially public key infrastructure, or PKI.
Reference: https://blog.csdn.net/baidu_36649389/article/details/53240579
