Trust self-signed HTTPS certificates with authentication challenge

During the development phase we often use self-signed certificates to deploy our backend rest API. However, calling the API when it is called in iOS is unsuccessful because the certificate is not trusted. At this point we need to customize the validation logic of the certificate by implementing some network callback functions. (in iOS, you typically use Urlsession (nsurlsession in OC) for network communication, as in urlsession, for example). First we need to understand a few concepts.

Challenge

Challenge is a professional term in computer security. The literal meaning of the question. is to verify the user's identity, send a challenge to the visitor, and then the visitor needs to provide a correct answer to identify. The simplest is that we visit a need to authorize the site, the site backstage through the HTTP protocol to send a query to the browser to ask the user to enter a user name password. (The browser will pop up a dialog box for user input)

In the network-related library for iOS, the following classes are provided to describe abstract entities in the process of challenge.

Urlprotectionspace

This represents a protected area on the server where a challenge is required to access this piece. He has the following common properties:

//Realm is a protectionspace identifier, and a set of resources on the server is marked by realm as a set of resources (Protectionspace) with the same authentication method. @property (Nullable,ReadOnly, copy) NSString *Realm;//the server on which the resource resides@property (ReadOnly, copy) NSString *host;//server port on which the resource resides@property (ReadOnly) Nsinteger Port;//get the resource's protocol resources@property (Nullable,ReadOnly, copy) NSString *protocol;//verification method used in the challenge@property (ReadOnly, copy) NSString *authenticationmethod;

The following types of challenge verification methods are commonly used:

Nsurlauthenticationmethodhttpbasic//http Basic Authentication, the server asks the client for the user name, password

nsurlauthenticationmethodclientcertificate//client certificate validation, the server queries the client for client identity certificates

nsurlauthenticationmethodservertrust//Server-side certificate validation, the client authenticates the server-side certificate. Server-side certificate validation in HTTPS belongs to this one.

Urlauthenticationchallenge

This is the server side of the client's description of a challenge. It has the following common properties:

// The corresponding Protectionspace @property (readonly, copy) Nsurlprotectionspace * Protectionspace of the question; // indicates the sender of the challenge ReadOnly, retain) id<nsurlauthenticationchallengesender> sender;

Urlcredential

He is the client's response to the server-side challenge. Depending on the authentication method, there are several urlcredential:

• Urlcredential based on username and password
• Client certificate-based Urlcredential
• Server-side certificate-based urlcredential//is where we verify that the server-side certificate needs to be used.

They correspond to the three tectonic modes of urlcredential respectively. See the Apple development documentation for details

Sectrust

He is the wrapper for the certificate and accept policy in iOS. System-to-background certificate validation is actually a validation of the object. Learn more about building an Apple development document

Well, all the conceptual stuff is done here. Finally, all these concepts can be combined into a callback method of Urlsession to validate the certificate itself. The code is as follows:

This is a function that is always defined by the nsurlsessiondelegate, so you first need to set the delegate of the Nsurlsession object and then implement the method delegate the object.
- (void) Urlsession: (Nsurlsession *) session Didreceivechallenge: (Nsurlauthenticationchallenge *) Challenge Completionhandler: (void(^) (nsurlsessionauthchallengedisposition disposition, nsurlcredential *credential)) Completionhandler{
Check if the authentication method of the challenge is server-side certificate verificationif([Challenge.protectionSpace.authenticationMethod isequaltostring:nsurlauthenticationmethodservertrust]) {
Here, the certificate packaging object to get, Sectrustref trustref=[Challenge.protectionspace Servertrust];
Using the certificate Sectrust object to construct the urlcredential, the default implementation of the system should be to verify the sectrust, and here our purpose is to trust all certificates.        So skip the verification step. IDTrustcredential =[Nsurlcredential Credentialfortrust:trustref];
The callback function tells the system about the urlcredential of the challenge.    Completionhandler (nsurlsessionauthchallengeusecredential, trustcredential); } Else{Completionhandler (nsurlsessionauthchallengeperformdefaulthandling, nil); }}

Trust self-signed HTTPS certificates with authentication challenge