Regression #16688
openCreating a CA certificate with Trust Store checked is not trusted
100%
Description
Hello,
I have created a CA certificate in pfSense with "Trust Store" checked, and used it to create a server certificate. Then I installed the CA certificate on some clients (an Android phone and a Windows PC), and installed the server certificate on a Web server running a REST API. The clients can connect without problem with HTTPS, so to me the certificates works and the server is correctly configured. However the Dynamic DNS service of pfSense fails to connect to the server with HTTPS, it can only connect with HTTP. The hardware affected is a Netgate 8200 running pfSense Plus 25.11.1.
I used the command "curl -v" on pfSense to check how the router connects to the server and got:
* Trying 10.0.2.4:8081...
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1570 bytes data]
* CAfile: none
* CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [94 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1235 bytes data]
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
} [2 bytes data]
* SSL certificate problem: unable to get local issuer certificate
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* closing connection #0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.
After that I did the following test:
- Execute the command "ls /etc/ssl/certs" (which seems to be where CA certs are supposed to be stored, at least for "curl")
- Create a second CA certificate with "Trust Store" checked
- Execute the command "ls /etc/ssl/certs" again to compare what changed
But no file was added even after a reboot. However if I use "ls -l", I can see the date on all files does change every time I change the configuration of pfSense, so at least my changes seems to be processed.
I don't know the details on how pfSense is supposed to manage its CA certificates, but for me it seems either the "Trust Store" checkbox is broken, or its implementation don't do anything useful. What do you think? Did I misunderstood something?
Related issues
Updated by Manuel Carrera 1 day ago
Also about the Dynamic DNS service: If you do not check "Verify SSL/TLS Certificate Trust", isn't pfSense supposed to ignore the unknown CA error anyway? Because in this case nothing happens when I check it, the connection fails in all cases. Should I create another bug?
Updated by Jim Pingle 1 day ago
- Tracker changed from Bug to Regression
- Project changed from pfSense Plus to pfSense
- Category changed from Certificates to Certificates
- Status changed from New to In Progress
- Assignee set to Jim Pingle
- Target version set to 2.9.0
- Affected Plus Version deleted (
25.11.1) - Plus Target Version set to 26.03
The source path for local trusted certificates that certctl reads changed upstream for some reason, updating the path fixes it. Commit coming momentarily.
diff --git a/src/etc/inc/certs.inc b/src/etc/inc/certs.inc
index f804d0c0cd..e98c8e44ee 100644
--- a/src/etc/inc/certs.inc
+++ b/src/etc/inc/certs.inc
@@ -2552,8 +2552,8 @@ function cert_notify_expiring() {
******/
function ca_setup_trust_store() {
- /* This directory is trusted by OpenSSL on FreeBSD by default */
- $trust_store_directory = '/usr/local/etc/ssl/certs';
+ /* Source for local CA certificates which will be trusted after "certctl rehash" runs */
+ $trust_store_directory = '/usr/local/share/certs/trusted';
/* Create the directory if it does not already exist, and clean it up if it does. */
safe_mkdir($trust_store_directory);
Updated by Jim Pingle 1 day ago
Manuel Carrera wrote in #note-1:
Also about the Dynamic DNS service: If you do not check "Verify SSL/TLS Certificate Trust", isn't pfSense supposed to ignore the unknown CA error anyway? Because in this case nothing happens when I check it, the connection fails in all cases. Should I create another bug?
That option should skip CA validation, it might be a separate bug if it can be reproduced on its own.
Updated by Jim Pingle 1 day ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset 37884c3039756e3868b7f995a3329793b771a6b0.
Updated by Jim Pingle 1 day ago
Affected users can install the System Patches package and then create an entry for 37884c3039756e3868b7f995a3329793b771a6b0 to apply the fix, or copy/paste the diff above into an entry manually.
Updated by Marcos M 1 day ago
Regarding the DDNS cert verification option, see: https://redmine.pfsense.org/issues/16690
Updated by Manuel Carrera 1 day ago
- Applied patch and rebooted
- Executed again the command "curl -v" with my server -> Connection OK
- Used the Dynamic DNS service again with my server -> Connection OK
So I can confirm the fix solved the problem. Thanks for your reactivity!
Updated by Jim Pingle 1 day ago
- Related to Bug #16673: LDAPS TLS connections intermittently failing with 'Unknown CA (48)' error added