PB with client configuration after hardening

[Nicolas THOREZ]

Hi.

I have a fressh install of minarca server. For testing purpose, some clients were configured with default server address (http://a.b.c.d:8080).

Since I have hardened server with your documentation (https://nexus.ikus-soft.com/repository/archive/minarca/6.0.3/doc/networking.html), I must reconfigure clients with new address (https://my.domain.tld).

However, clients cannot connect with this address, even if website is accessible from browser.

For additionnal information, I don't use Let's Encrypt certificate, I use one from my PKI and domain is local only.

Ther's no log on server side. On client side, I've this log :

Regards.

Nicolas THOREZ

[Patrik Dufresne]

Hello Nicolas,

This is strange. Could you share your logs ? The exception raised when this occurs would be a great help to understand what is going on. Location of the logs are documented in the troubleshooting section.

--
You received this message because you are subscribed to the Google Groups "Minarca Data Backup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minarca+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/minarca/67b60a6a-91db-439d-bd83-905cc58ea8b2n%40googlegroups.com.

--

** Par mesure d'efficacité, je consulte mes courriels une fois par jour.

IKUS Software

https://www.ikus-soft.com/

514-971-6442

St-Colomban, QC J5K 1T9

[Nicolas THOREZ]

Here all logs I have.

[Patrik Dufresne]

Hello Nicolas,

Thanks for sharing your logs.

I'm not sure what exactly you are doing, but apparently the connection to the hostname you provided "https://lbg-backup-1.lbg1.mtg" is not working. Indeed it's not working from my end either. It's most likely an internal network ?

The only relevant log for this issue is "minarca.log". You don't need to share any other logs file. Could you delete this log file and run minarca with "--debug" flag ? This will increase the verbosity of the logs.

P.S.:  Attaching a file to the email is fine. But your email goes into a queue for approval. No need to send it multiple time. ;)

To view this discussion visit https://groups.google.com/d/msgid/minarca/0cac9db3-8a66-4d49-8908-80538edd606cn%40googlegroups.com.

[Nicolas THOREZ]

Hi.

The server URL is effectively a local domain. We want use Minarca for internal use.

I've launch minarca agent with --debug flag but the log file doesn't show any clue.

I was thinking about a behavior we encounter with our PKI and some Linux tools. If we don't specifically specify the CA certificate, the tools fail to establish the HTTPS connection.

On Windows, you normally just add this certificate to the OS certificate bank and that's it, but some software like Firefox uses its own bank.

Maybe, problem is there. How minarca work with this kind of certificates ? Can I ignore certificate error to test this ?

[Patrik Dufresne]

Hello Nicolas,

> I've launch minarca agent with --debug flag but the log file doesn't show any clue.

Too bad for the logs, indeed the current version of minarca is hiding crucial details regarding the exact problem. Will check to get this fixed in a future version.

> was thinking about a behavior we encounter with our PKI and some Linux tools. If we don't specifically specify the CA certificate, the tools fail to establish the HTTPS connection.

> Maybe, problem is there. How minarca work with this kind of certificates ? Can I ignore certificate error to test this ?

Good question !

Minarca is using `requests` to make https connection to the server. So any documentation about requests should work with Minarca. It seems you can define REQUESTS_CA_BUNDLE environment variable. With your own CA.


https://requests.readthedocs.io/en/latest/user/advanced/#ssl-cert-verification




Internally `requests` is not using Windows CA Bundle. It uses certifi instead. So if you are using your own CA. That might explain why you are facing issues with SSL.





To view this discussion visit https://groups.google.com/d/msgid/minarca/65bd7e51-1125-4f27-928d-606394e6942en%40googlegroups.com.

--

ATTENTION : Je serai en vacances du 2 au 21 mai 2025.
ATTENTION: I will be on vacation from May 2 to May 21, 2025.

[Nicolas THOREZ]

Hi.

So, that's the point.

I've tried with a fqdn with a publicly trusted certificate and It's works.

Next, I've added the environment variable REQUESTS_CA_BUNDLE (value : /path/to/ca_fullchain.pem) and after reboot of client computer, the new configuration with fqdn and privately trusted certificate woks.

Case closed. Thanks for support.

Nicolas THOREZ

[Patrik Dufresne]

Hello Nicolas,

I'm glad you figured out how to get this working for your needs. I've also created an issue in Minarca to investigate the possibility of using OS certificates, at least on Windows, as it's probably the expected behavior.

https://gitlab.com/ikus-soft/minarca/-/issues/309

To view this discussion visit https://groups.google.com/d/msgid/minarca/bcc5e96e-a245-4962-8a95-26e36024c1b3n%40googlegroups.com.

[Patrik Dufresne]

Hello Nicolas,

I'm working on a fix to better support Operating system Certificates instead of using embedded one. Would you be willing to test if this is working for you ?

The following link will work for a week:

https://nexus.ikus-soft.com/repository/archive/minarca/6.1.0b3.dev1%2Bg69fa1dc/minarca-client_6.1.0b3.dev1%2Bg69fa1dc.exe

For anyone interested, let continue the discussion in this ticket:
https://gitlab.com/ikus-soft/minarca/-/issues/309

[Nicolas THOREZ]

Hi.

I'll check and let you know.

Regards.

[Nicolas THOREZ]

Hi.

The tests were completed without any problems.

The root and intermediate certificates were saved to the computer's certificate store during the first test and to the user's certificate store during the second.

Regards.

[Patrik Dufresne]

Good news !

The final fix will be included in the next release planned for release before the end of June.

Thanks for taking the time to test.

To view this discussion visit https://groups.google.com/d/msgid/minarca/f4c284da-dc59-4149-9847-590e63ecacf9n%40googlegroups.com.