FortiAuthenticator
FortiAuthenticator provides centralized authentication services for the Fortinet Security Fabric including multi-factor authentication, single sign-on services, certificate management, and guest management.
asanzd
Staff
Staff
Article Id 301058
Description This article describes which kind of certificate is necessary to prevent the 'Untrusted Certificate' message from appearing on FortiTokenMobile when performing a push of a Token.
Scope FortiAuthenticator, FortiTokenMobile
Solution

The push token notification sent from FortiAuthenticator to FortiTokenMobile is a useful feature to return a 2FA token code.


If FortiAuthenticator has a 'default' certificate as-is, there will not be any message on FortiTokenMobile about an 'Untrusted Certificate'. However, upon changing the HTTPS Certificate and Certificate Authority (CA) certificate for FortiAuthenticator (via System -> Administration -> System Access), this message can appear if it is not well signed. The certificate does not need to be signed by a public CA.


The FortiAuthenticator certificate has to be signed by a remote CA (private or public). This article will focus on an example with a private CA. The certificate has to be requested for a public IP/FQDN in this field:

 
FAC_FQDN.png

 

The certificate and CA have to be imported under Certificate Management -> Certificate Authorities:

  • Certificate: End Entities/Local Service.
  • Remote CA: Certificate Authorities/Trusted CA.

Follow the process and upload the files for CA:

 

CAtrusted.png


Upload the certificate itself with the key (if the format is .crt, it requires the private key):

 

pkcs_cer.png

 

Note that if the certificate is properly generated (Web Server Authentication), the certificate allows FortiTokenMobile to connect to FortiAuthenticator without any message and without the need to import the remote CA (even a private one) on the mobile device where FortiTokenMobile is installed.

A signed certificate for a server just needs Server Authentication usage (which comes by default).  Anyway, *notice* in the image it shows *additional 'extra' usages* -line 'KeyUsage'- but they are not needed for the FortiAuthenticator certificate:

 

FAC_certifi.png


Also, if a FortiGate publishes the FQDN of FortiAuthenticator doing some SSL inspection, the FortiAuthenticator certificate can be imported as usual on FortiGate (Local Certificates), and the remote CA will also be imported. Below is an example of using this profile to protect the FortiAuthenticator identity with the certificate uploaded:

 
 

SSL_insp_FG.png

 

No 'Untrusted Certificate' message will appear on FortiTokenMobile when pushing the token.

Another important thing to note is that on FortiAuthenticator, 'Local Service' certificates cannot be exported with its private key. This is the reason why FortiAuthenticator certificates used on a FortiGate in the middle (doing SSL inspection) must be signed by a remote CA. The ortiAuthenticator certificate itself cannot be exported with the key.


FortiAuthenticator and FortiGate will use the same certificate signed by a remote CA.

 

The following message can appear if a certificate is not properly signed or is on FortiGate MITM and does not correspond to the final FortiAuthenticator server:

 

push.jpg

 

This is not the same case as for SSL VPN, where the FortiGate's certificate has to be public or a private CA has to be imported on the endpoint PCs.

 

Apart from this, server certificates can also be imported on FortiManager and installed on FortiGate:

Technical Tip: How to install CA certificate on FortiGate using FortiManager 

The SCEP protocol on FortiAuthenticator is not valid for this goal (FortiAuthenticator server certificate for push return), as they are expended for FortiGate and not for FortiAuthenticator.

 

Final note: the push token answer can be seen on https://IP_FAC/debug/ under Others -> REST API. These logs include info such as the following:

 

2024-02-21 07:17:17,448 information 23461 139816552470272 Receiving HTTP POST request at "/api/v1/pushauthresp/" from "79.117.26.119" (Data={'session_id': 'cUrztoSXbpmLScVJN9+BbeFd/dG51S43', 'token_code': '779236', 'action': 'validate'})

2024-02-21 07:17:17,470 information 23461 139816552470272 HTTP POST request from "79.117.26.119"succeeded for "/api/v1/pushauthresp/" (Response: HTTP 200, {'success': True, 'message': '[Verified] Login attempt approved.', 'sn': 'FTKMOB36DD7053BE'})

 

These include session_id and token_code in the response, as well as the success of this API POST request to FortiAuthenticator (as in the second message). It is important to notice that session_id is the id provided in the Radius authentication process in FortiAuthenticator. So it links the answer to the previous session initiated on Radius authentication. 


Summary of the Radius authentication process (FAC_IP/debug/radius):

access-request from FortiGate to FortiAuthenticator:

 

2024-02-28T07:19:10.007569+01:00 FortiAuthenticator radiusd[29653]: (3) Received Access-Request Id 6 from 198.18.11.1:9870 to 10.130.14.211:1812 length 113

 

access-challenge from FortiAuthenticator to FortiGate :

 

2024-02-28T07:19:10.029929+01:00 FortiAuthenticator radiusd[29653]: (3) facauth: Partial auth done, challenge for token code

2024-02-28T07:19:10.030360+01:00 FortiAuthenticator radiusd[29653]: (3) facauth: Sending Access-Challenge.

 

push notification process initiated by FortiAuthenticator:

 

2024-02-28T07:19:10.317766+01:00 FortiAuthenticator radiusd[29653]: (4) facauth: Sending FTM push notification

...

2024-02-28T07:19:10.324408+01:00 FortiAuthenticator radiusd[29653]: (4) facauth: initiate_push_auth:Initiating push auth session with session_id = 0MfCEwTnKQnx0uOeRggt0VVJOx0QXOel---<----- This is the session_id commented (in a unique flow, it is the same id shown in REST API).

....

 

Related articles:

Troubleshooting Tip: Invalid server certificate - FortiToken Mobile cannot validate the server certi....

Technical Tip: FortiToken Push on FortiAuthenticator: operation flow and details.