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
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'.
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
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
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.
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.
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.
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.
Instructions on how to enable 'debug' logging on a production device
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.
The debug level can be modified throught the launchagent on OSX.
The possible values are: info|warn|debug
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
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:
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 :-).
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:
In some cases, the t1c-reg.exe will not be running. When that's the case, the connector installed on the device is running in standalone mode. Standalone mode is the mode used when the device is NEVER part of a shared environment (VDI, Citrix, Remote desktop, ...). By default, the connector is installed with a registry process running along the api and sandbox process.
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"
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 :-).
This page summarized 'know' solution for connector connection troubleshooting
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
You can easily test if the connector is running correctly using the following URL:
Depending on the connector (partner related) the port can be different, make sure to verify on which port your connector should be running
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.
When the connector is not reacting, but the installation has succeded, a DNS Rebind policy can forbid the communication form a web application to the connector's domain name. The default domain name used is: https:t1c.t1t.io
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
[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:
Depending on the connector (partner related) the port can be different, make sure to verify on which port your connector should be running
[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
Depending on the connector (partner related) the port can be different, make sure to verify on which port your connector should be running
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.
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.
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.
More information on 'known' solution for anti-virus services can be found: Troubleshooting
Smart Card Reader Issues Tracker for Sonoma
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:
The initial solution prior to 11/2023 was very elaborate, but was made easy by applying a single command in a MAC OSX terminal:
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.
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:
After executing a driver switch, we have noticed that a restart is mandatory!
Issues related to device time not in sync
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).
To solve this problem the followin steps need to be executed:
remove all device related keys
restart the connector
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
Those files will be automatically generated by the connector after the next step
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)
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
Those files will be automatically generated by the connector after the next step
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)
