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

[oak-si]

When setting up SSL on our servers, we usually have to use the .crt file, the ca-bundle, and the .key. Following the documentation at https://rennokki.gitbook.io/soketi-docs/getting-started/ssl-configuration, I'm able to set the certificate and key and the server is running. We're using Laravel Echo and that can connect to the soketi server, but when using Laravel to broadcast an event through soketi, we get an error of: curl: (60) SSL certificate problem: unable to get local issuer certificate

I'm thinking we need to also provide the ca-bundle somehow. We also get the error when we curl the web socket server. For example, curl https://my.site.com:6001.

The Laravel broadcasting.php file is configured following the information here: https://rennokki.gitbook.io/soketi-docs/getting-started/backend-configuration/laravel-broadcasting. For the pusher/pusher-php-server package, we're using version 7.0.2.

I was wondering if there was a way to include the ca-bundle or if there was another suggestion on what we could do. Thanks in advance!

[jstark518]

Server running on windows?

[oak-si]

The server is running on Debian 9.

[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

[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.

[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.

[oak-si]

Thanks! I appreciate your reply and explanation.

[rennokki]

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

[oak-si]

Surprise. Good to know!