I have to deal with MITM bullshit too. I'll figure out a solution soon

@ikey Ever figure that out? My "google-foo" is failing me, and I too have a MITM SSL firewall to deal with at work... :/

Any update on this?

I installed Solus at work and came across the same issue. After installing my company's SSL certificates I am able to browse https://packages.solus-project.com/ but I still get the error when I do "sudo eopkg update-repo".

Thanks,
Erik

I've dabbled a bit, my issue is: Where are the certificates stored / how to tell OpenSSL to regenerate the certificate store?

I personally assumed that it's /etc/ssl/certs/ca-certificates.crt holding all pem text certificates, which turned out to be wrong.

So converting all *.crt to pem, saving them to text and appending them to /etc/ssl/certs/ca-certificates.crt didn't make any difference at all.. so when or how does openssl relad its truststore?

Currently I try the converting with the following script, copying / echoing them into ca-certificates.crt later.

My guess is that this method is almost right, but I'm missing the part where I tell openssl actually to use those certificates.

for f in *.crt; do
  [[ $f =~ ^(.*?)\..* ]]
  openssl x509 -text -in "$f" -inform der -outform pem > ./pem/${BASH_REMATCH[1]}.pem
done

cd pem
for f in *.pem; do
  new_file=$(openssl x509 -hash -in "$f" |head -n 1
  mv "$f" "new_file.pem"
  ln -sf "$new_file.pem" "$new_file.0"
done

Might be missing the c_rehash ?

Actually got it working by now. My fault - I missed a damn certificate in the chain which was why it didn't work :-)

Basically, what is required to get it working properly:

for f in *.crt; do
  [[ $f =~ ^(.*?)\..* ]]
  openssl x509 -text -in "$f" -inform der -outform pem > ./${BASH_REMATCH[1]}.pem
done
cp *.pem /etc/ssl/certs
c_rehash
cat /etc/ssl/certs/*.0 > /etc/ssl/certs/ca-certificates.crt

[edit]
if you have cross signing certificates, you may need to cat .1, .2, .3 etc. as well..
Also make sure your SUB-CAs go into the ca-certificates.crt BEFORE the RootCA. Otherwhise it will fail (!).

What I'd like to know additionally is the way planned forward on this @ikey .

I'm willing to look a bit closer into this since I'm obviously one of the few having this issue, but we'll need a decision on where we are heading. I currently see two options:

• Going with pki/trust creating a compat config (which will require quite a few packages patched, this caused quite some issues on Arch when they switched).
• Going with a tool like update-ca-certificates (like Ubuntu, RedHat, LFS and others, though, there are several different tools) to properly handle custom root/sub CAs.

If somebody knows additional / better ways - be my guest :-).

I am well aware this is not a pressing issue for most users outside bigger corporate environments, and not even for me now I know how I can handle it...

@STiAT : Thanks for the workaround instructions!
Do you know if the manually added certificates are removed if the system updates the certificates via the package manager?

I would also appreciate an easier way to add/manage system wide certificates.

@palto42 didn't have this one on the radar, sorry.

Yes, they get removed whenever ca-certificate package is updated, because it seems we're not generating the ca-certificates.crt at install time, but supply it by the package. At least I had to cat the *.0 into the ca-certificates.crt whenever the package was updated.

So ideally we need to move out setup to work more like Fedora certs..

Ideally, yes. I've looked that up, and Fedora / RHEL seem to have switched to the p11-kit trust module as well with F19 when they introduced shared system certs.

The trust module is a module within the p11-kit repository / source release, which needs to be built seperately and can handle extra trust anchors (parameter to configure specifying the main ca-cert bundle and the extra directory for the trust-anchor). It's basically the way Arch uses as well.

Useful links:
https://fedoraproject.org/wiki/Features/SharedSystemCertificates
https://p11-glue.freedesktop.org/sharing-trust-policy.html
https://p11-glue.freedesktop.org/trust-module.html

From our perspective, p11-kit is already included in Solus by default. So what we should try to do at the same time is ensure that ca-certs becomes stateless, and we have a proper transition policy in place to the p11 method

Also this one is a big invasive change, so we need to ensure that we design a test for this to handle updating. Remember we're updating over SSL, so pulling the carpet out with SSL certs needs to be considered.

p11-kit yes, but not p11-kit trust (which is in p11-kit/trust directory and needs to be built seperately, it isn't built by default with p11-kit by default as I know).

Did something change with the last update ??

Impossible de récupérer le fichier de destination "https://packages.solus-project.com/shannon/eopkg-index.xml.xz.sha1sum" : [Errno 14] curl#60 - "Local CA certificate failed"

I always had to deal with firewall and certificates at work but somehow it worked. When the certificate was loaded by the web browser it worked. Not really debugged this behaviour not even sure my solution was related to the browser caching the certificate.

Yep obvisouly didn't add it to my trusted certs

Preetty sure they change ssl firewall certs at work for windows workstation withtout tellin'