Generating a HAR file for support

In some cases the Support Desk will ask for a HAR file. This means an export of the functions that a web-page is executing. This is to see that all the functions that call the Trust1Connector are executed correctly.

Before you use the web application open the developer tools. This can be done by right clicking and click on inspect

This will open a window like this

Next navigate to the network tab in the inspect window

When this is done, use the web application's functionality and when you are finished or come to an issue you can use the download button to get a HAR file, save the file to your system and send this to the Support Desk

Windows

Error while retrieving readers

Is the smartcard service running?

The Smartcard service is a Windows service that manages the connection to the eID and card reader. Therefore, this service must be running for you to be able to access the eID. You can check this as follows:

• Open "Windows Services".

• Search for "Smartcard service" as shown in the following screenshot:

Check the following Smartcard service settings (based on the screenshot above):

• The status column for the Smartcard service shows 'Running'.

• The 'Log On As' column shows 'Local Service'.

Are the Smartcard service settings NOT as they should be? Then do whichever of the following two options applies:

1. The Smartcard service is not running.

Start the Smartcard service, as follows:

• Double-click the Smartcard service.

• Click 'Start' and then 'OK'.

2. The Smartcard service is not logged on as a 'Local Service'.

• Double-click the Smartcard service.

• Select the second tab, 'Log On'.

• Select 'This account'.

• Click 'Browse'.

• In the white text box, type: loc.

• Then click 'Check names'.

• The name 'Local service' now appears in the text box.

• Then click 'OK'.

• Leave the password boxes empty.

• Click 'Apply'.

• Click 'OK'.

• Go back to the first tab, 'General', and restart the service.

• Click 'Start'.

• Click 'Stop'.

DNS probe finished nxdomain error

In some cases there is a possibility that the system is not able to retrieve the domain information, in this case the T1C is not usable. To solve this problem you can follow these steps described here; https://www.hostinger.com/tutorials/fix-dns_probe_finished_nxdomain

Error during installation MSI error 2502 or 2503

When installing the T1C the possibility of the errors 2502 or 2503 originate from the fact that permissions in the temp folder (C:\Windows\Temp) are not correct, and since the MSI installer relies on this they need to be correct. You need to have permissions next to the administrator rights.

You need to have permissions as <My User> next to the administrator rights.

More information can be found here; https://answers.microsoft.com/en-us/windows/forum/windows_8-windows_install/windows-8-install-some-software-using-msi/48881523-1a5d-4c43-abc4-01b1ce3ebf3a

Antivirus

The Trust1Connector and some installation files are digitally signed. On some machines however the Trust1Connector is flagged/blocked by an antivirus. Disabling the antivirus temporary can allow the user to install the Trust1Connector for some antivirus tools. Below we provide procedures for some antivirus softwares to be able to install the Trust1Connector.

ESET

If the user receives an notification that a script from the Trust1Connector is blocked as shown below:

The procedure at https://support.eset.com/kb2908/?locale=en_US&viewlocale=en_US can be used to solved the issue.

Kaspersky

When using the Kaspersky and kaspersky web protection you can add an exclusion rule to the belfiusweb page. After you added this rule, restart the computer to make sure all settings are applied.

A9. T1C List Type Conent Issue

If the connector is not starting with the error message: "Can not contact the DS service"

Go to the user folder in %LocalAppData%

Go to BelfiusConnector folder and remove the selected files below:

Restart your pc or mac, and the restart will re-initialise the device keys.

The problem should be solved after executing this step.

Introduction

The connector can only work when the device date/time is correctly set. This is due to the security applied on exchanged tokens and keys.

When a connector has been installed on a device, at a moment which is in the past (other day/time), this results in the connector not working, even though the date/time has been set correctly on the system (post-installation).

Solution

To solve this problem the followin steps need to be executed:

• remove all device related keys

• restart the connector

Windows

Go to the installation folder of the connector:

%localappdata%/Trust1Connector

Delete all security relate files (selected below):

Those files are:

• device.priv

• device.pub

• device_der.priv

• device_der.pub

• device_x509_der.pub

• ds-ssl.json

• ds-txs.bck

Restart the connector by executing the 't1c-launch'

The process will be stopped, and restarted. The 't1c-launch' process must stop running, and the new processes will trigger the re-generation of the new keys.

Due to this action, the device performs a new registration to the Distribution service, this can be verified in the api.log file (in the /Logs folder)

Mac OSX

Go to the installation folder of the connector:

cd ~/Library/Application\ Support/Trust1Team/Trust1Connector/

Open the folder in finder:

open .

Delete all security relate files (selected below):

Those files are:

• device.priv

• device.pub

• device_der.priv

• device_der.pub

• device_x509_der.pub

• ds-ssl.json

• ds-txs.bck

Use the terminal to open the connector installation folder:

cd ~/Library/Application\ Support/Trust1Team/Trust1Connector

Execute the t1c-launch to restart

./t1c-launch --restart

The process will be stopped, and restarted. The 't1c-launch' process must stop running, and the new processes will trigger the re-generation of the new keys.

Due to this action, the device performs a new registration to the Distribution service, this can be verified in the api.log file (in the /Logs folder)

Can't Connect to the connector after installation

The connector is using a DNS (depending on the connector partner), with a default value of:

The given URL is registered with DNSSEC enabled, and resolves to a 'localhost' domain.

Although the connector can run in a different mode (http, localost, custom domain name, etc.), to solve the above issue, the following causes are probable:

• DNS Rebind is enforced from your router

• The domain name is not whitelisted in your internal network

• A local proxy is running and prevents the internal connector communication

• An antivirus is blocking the connector communication

Solve the DNS Rebind Issue

Modifying your hosts file enables you to override the domain name system (DNS) for a domain on a specific machine.

Modifying your hosts file causes your local machine to look directly at the Internet Protocol (IP) address that you specify.

Modifying the hosts file involves adding an entries to it. The entry contains the IP address to which you want the DNS to resolve and a version of the Internet address.

There are 2 approaches to fix the issue:

• update the 'host' file of the device (needs admin rights)

• update the local router which enforces the DNS Rebind

Update the 'host' file on the device

[MAC OSX]

The admin password will be asked in the command line. If you open the file with another editor, a pop-up will ask you for the administrator password.

The file will be shown (the example can be different from what is configured on your device)

We need to add an additional line to this file:

Save the file, and test if the connection is working:

[WINDOWS]

Open Notepad or an editor of choice and run as administrator the following file:

We need to add an additional line to this file:

Select File > Save to save your changes and test using the following URL in your browser

Update the local router which enforces the DNS Rebind

Solve the domain name whitelisting

The issue happens typically when the device is owned by an administrator in a controlled environment. Any router or firewall, sitting in between the connector and the internet, must comply to whitelist the following domain names by default:

• t1c.t1t.io

• ds.t1t.io

The latter is a central distribution service, which provides user with installation packages or updates. No personal data ever leaves the local device without explicit user consent.

Solve the local proxy issue

A local proxy can redirect or capture communciation using a 'localhost' URL. Many proxy solutions exists, so to solve the issue please read the documentation of the specific proxy and configure it to allow or exclude the connector from the applied policies.

Solve the antivirus issue

An anti-virus has functionalities to protect you from malicious software components. When an anti-virus is present on your device, please allow the connector processes to be trusted.

Introduction

By default, the connector has tracing set to 'info', which limits logging output to it's bare minimum.

For unexpected issues in production, the debug flags have been compiled in the connector, but they are not activeated by default.

This page describes how to enable debug logs for OSX and Windows.

Mac OSX

The debug level can be modified throught the launchagent on OSX.

The possible values are: info|warn|debug

Update log level

Go to the directory of the launch-agents:

cd ~/Library/LaunchAgents/

A connector .plist file can be found (depending on the partner, the naming is different):

Default Trust1Connector launch-agent:

com.t1t.t1c.api.plist

The file has a parameter declaring the log level:

The following line can be modified for example to 'debug' log level:

for example:

update to 'debug' level

Restart the Connector service

After modifying the launch-agent, the service must be restarted. To do so, you need to use launchctl:

Stop the service:

launchctl unload com.t1t.t1c.api.plist

Start the service:

launchctl load com.t1t.t1c.api.plist

The activity monitor can be used to verify if the processes are started correctly:

Verify logging output

Go to the logs-folder where the connector is installed (depends on the partner configuration), by default:

cd ~/Library/Application\ Support/Trust1Team/Trust1Connector/logs

Open the log file and notice the debug logging appears :-).

Windows

The connector, upon installation, creates a Windows registry entry to start when a device reboots/restarts. The entry declaration can be found when using the 'registry editor' on Windows with the following path:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]

What happens is that the t1c-launch executable is called to bootstrap/initialize the connector processes. After a succesfull bootstrap, the t1c-launch process is killed, and the following 3 processes are running:

Update log level and restart

On Windows, the process to enable a different log level is easier than with Mac OSX.

You just need to call the t1c-launch process with additional command line parameters.

To find the t1c-launch binary, you typically can find it in the 'LocalAppData' folder of the logged-in user:

In Windows Explorer type the following path:

%localappdata%

Select the folder from the partner who's connector has been installed:

Open a terminal command, you can do this by starting a n ew command terminal form the Menu Search, or by typing: 'cmd' as a path in the Windows Explorer (opens a terminal window directly in the present folder).

Execute the launcher with new parameters:

t1c-launch --restart --log "none,t1c_rust_api=debug"

Verify logging output

Go to the logs-folder where the connector is installed (depends on the partner configuration), by default:

%localappdata%/Trust1Connector/Logs

Open the log file and notice the debug logging appears :-).

Overview

Starting from OSX Sonoma, smart card readers for Mac can fail for the following use cases:

• detect card reader

• execute transaction (digital signature or authentication)

The general end-user experience is that the smart card communication fails (card reader disseappears or the transaction fails).

A very great shout-out to Ludovic Rousseau who initially did a follow-up on impact of smart card readers in Sonoma:

Reported Bug to Mac OSX:

OSX Forum

Solution

The initial solution prior to 11/2023 was very elaborate, but was made easy by applying a single command in a MAC OSX terminal:

What does the command execute/change?

The command switches the MAC OSX implementation of the CCID drivers to the legacy version (the version working prior to Sonoma).

As MAC OSX defaults using a custom CCID implementation, which still have some issues, switching to the old version is a temporary stolution.

How to roll-back to MAC OSX CCID implementation?

Form a specific moment (not at the time of writing), switching back to the default CCID implementation can be done using the following commands (in a terminal):

Check if the built-in Apple CCID driver is active

If the former command results in:

This means that the built-in Apple driver is active.

The result is 1 so the "external" (non-Apple) CCID driver is enabled.

Returning back to default, execute: