Solved certctl rehash broken after upgrading to 14.3

Give the result of: freebsd-version -kru

/usr/sbin/certctl is a sh script. On my 14.3-RELEASE, the only tr is line 76:
Code: 
eolcvt()
{
    cat "$@" | tr -s '\r' '\n'
}

Do you have the same?
 
Yes, line 76 for me as well.

Output of freebsd-version -kru
14.3-RELEASE
14.3-RELEASE
14.3-RELEASE-p1

Same result & output on all of the 25 systems I've upgraded so far. Fortunately, the certctl script from 14.2 runs correctly on 14.3, so I have a workaround in the meantime.
 
Ok. The upgrade seems complete.
I tried certctl rehash on a 14.3-RELEASE and it works (added a certificate to see). So, you may have something particular on this machine.
 
Interesting. On my 13.5 & 14.2 servers I get this output (which I've seen in previous OS versions as well):

Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
Scanning /usr/local/share/certs for certificates...
Scanning /usr/local/etc/ssl/certs for certificates...

But on my 14.3 instances on an arm64 VM the command runs, but without the Scanning directories messages.

Emrion are you seeing the Scanning .... output when running it on your 14.3 installs?

I'll test adding some certs on a test instance tomorrow and see what happens.

Thanks!
 
twentythree said:
Executing the certctl rehash command after upgrading to 14.3 (amd64) returns a tr: Illegal byte sequence error.
Click to expand...
covacat said:
tr may fail if locale/llang is not set to "C"
Click to expand...

The use of tr(1) seems to have been introduced with commit src: 87945a0 on 2023-10-20; the accompanying D42490 - certctl: Convert line endings before inspecting files. mentions in its summary:
This ensures that certificate files or bundles with DOS or Mac line
endings are recognized as such and handled identically to those with
Unix line endings.
Click to expand...
Using awk(1)* instead of tr(1), should be more robust. It fully supports UTF-8 and, probably more important, it specifically matches the non-UNIX-like line ending by using \r$.


In the script /usr/sbin/certctl, instead of using:
Rich (BB code): 
eolcvt()
{
    cat "$@" | tr -s '\r' '\n'
}
Try:
Rich (BB code): 
eolcvt()
{
    cat "$@" | awk '{ sub(/\r$/, ""); print }'
}

Please report back if using this awk line in /usr/sbin/certctl (that is: in the 14.3-RELEASE version) works or does not work.


P.S.
twentythree said:
Fortunately, the certctl script from 14.2 runs correctly on 14.3, so I have a workaround in the meantime
Click to expand...
certctl.sh - 14.2-RELEASE does not implement the function eolcvt; it is not called in the do_scan function. However, do_scan in certctl.sh - 14.3-RELEASE does use eolcvt.
___
* using sed 's/\r$//' should also work, although, AFAIK, sed(1) does not fully support UTF-8.
 
After running certctl rehash substituting awk instead of tr, it seems to run but without the following output (as seen in 14.2 and earlier OS versions):

Scanning /usr/share/certs/untrusted for certificates...
Scanning /usr/share/certs/trusted for certificates...
Scanning /usr/local/share/certs for certificates...
Scanning /usr/local/etc/ssl/certs for certificates...

Also, after running it the AD CA certs are not added so when connecting to my company's AD servers via the ldaps interface I get this error:

Verify return code: 2 (unable to get issuer certificate)

Running certctl rehash from 14.2, I get the expected Scanning... output and am able to connect to the AD servers with the epected Verify return code:

Verify return code: 0 (ok)
 
Emrion said:
I will see tonight but I have an "exotic" locale, yet it works under 14.3-RELEASE. I think there are one or more cert in the OP machine that cause the problem.
Click to expand...
One of the certs was the issue! For some reason it did not like the CA root cert for our AD servers in .crt format, but certctl rehash works with the same cert in .pem format.

Thank you very much!
 
You must log in or register to reply here.
Back
Top