Is there a way to include the CA Bundle with the SSL certs?

[soketi]

Is there a way to include the CA Bundle with the SSL certs?

[jstark518]

I've had this happen on windows before, in the php.ini file under curl make sure the curl.cainfo = ... is set

https://curl.se/docs/caextract.html

[rennokki]

Tom Scott explained about the CA on Computerphile a while ago.

To sum it up, CA are just certificates of third parties like Google, Trust Global, or other parties that agreed with Microsoft or Linux distributions to share their certificates with devices. In fact, you can look at your device's Trusted Root Certification Authorities and see there are from certSIGN, Comodo, GlobalSign (these are mine, but they can differ).

Now, not having them is going to be a pain because you'd probably not be able to access the internet over SSL. These certificates are being renewed automatically and they can issue more CAs for other parties (like Let's Encrypt, for example), and this thing can chain more - Let's Encrypt can issue more CAs if they want to (and if their CA allows them), but you're probably using Let's Encrypt for normal Certificates issued for a specific website.

Example: certSIGN ROOT CA (CA) -> Some Other Party (CA) -> Let's Encrypt (CA) -> Your https:// certificate (CERT)

If you have Let's Encrypt CA in your device but don't have the first two, you'll get invalidated because they cannot be trusted (that's why they're called Trust Chains). Some Other Party (CA) must not provide a CA bundle because most obviously certSIGN ROOT CA is already trusted by most devices by default, but for Let's Encrypt, they need to provide Some Other Party's CA because most devices might not have it.

[rennokki]

Just figured out that uWebSockets.js actually has a path for CA but it was undocumented 😓: #285

[jstark518]

Server running on windows?

[oak-si]

The server is running on Debian 9.

[oak-si]

Thanks for the info. Yeah, I also saw that and tried that recommendation, but it's the same results.

[oak-si]

It looks like I've got it working, so I just wanted to leave an update to share my findings and thoughts here in case anyone else runs into the same type of issue. Or if I'm misunderstanding something, someone can also correct me.

I'm no expert when it comes to this topic of SSL, so I just did a little more reading on what certain files actually are. It started with the ca-bundle.

CA Bundle is the file that contains root and intermediate certificates. Together with your server certificate (issued specifically for your domain), these files complete the SSL chain of trust. The chain is required to improve the compatibility of the certificates with web browsers, email clients, and mobile devices.

From what I understood of the issue, our Laravel app couldn't verify the SSL certificate I used with soketi. The certificate I originally used was only the primary certificate, so it didn't include the intermediate or root certificates. I figured that since the certificate used wasn't the full chain, that was causing an issue. So after reading over what the ca-bundle is again, it made sense as to why I needed it. And in this case, I figured I'd just try combining the primary certificate and then the ca-bundle, in that order since it should end with the root certificate, so that I would have the full chain. And using this combined file, that got it working.

Just some extra details, but our certificates are from DigiCert and they're PEM encoded.

Now, if I were to run curl https://my.site.com:6001, I'll get OK. I'll need to play around with soketi some more, but it seems pretty solid so far.

[oak-si]

Thanks! I appreciate your reply and explanation.

[oak-si]

Surprise. Good to know!