Has handling of custom CAs / Proxy settings been improved in Seatable 6.x?

[abaer]

Just a general question regarding Seatable 6.0, because I couldn’t find any explicit information on this topic: Has the handling of custom (self-signed) corporate CAs been improved in 6.x (or even 5.3.12 - last time I checked was 5.2.7)

I’m referring to these past posts:

Suggestions for improved certificate (CA) handling

Your Setup: VMware ESX virtual machine in closed enterprise zone with own CA SeaTable Edition Enterprise SeaTable Version 5.2.7 (finally!) Describe the Problem/Error/Question: We run our on-premise SeaTable installation on a linux machine in our intranet. The intranet has its own CA and trust zone etc. Seatable does a fairly good job to build /etc/ssl/certs/ca-certificates.crt on startup, including custom CAs that are being mapped into /etc/ssl/certs/, but seems to forget that some third party…

Problem with importing Excel on server with self-signed certificate / custom CA

Hi, I have very specific problem with the following setup: My seatable enterprise server is run within a corporate intranet, not accessible from the outside. For security reasons, it runs on HTTPS. The server’s SSL certificate is signed by the company’s root CA. The CA’s certifcate is rolled out to all client machines centrally. So far, so good - Seatable works great from any browser. However, only the import of an Excel file into a new base fails with “internal server error”. This is what lo…

Build / configure Python runner with custom CA / Proxy settings

Your Setup: Self-Hosted Seatable 5.3.12 EE Running in internal network with own CA, Internet Access through local proxy (Squid) Describe the Problem/Error/Question: I had the usual problem that containers with internet connectivity in our network need to fulfill the following networking requirements: Communicate via TLS Verify server certificates signed by our internal CA Use a proxy server to connect to the internet For the standard python-runner, I found no standard way to configure eithe…

Specifically:

• I addressed the issue in the past that (at the time) 3 thirdparty components in seatable-server held their own CA stores, and did not care what /etc/ssl/certs/ca-certificates.crt contained. I noticed that the seatable container executed update-ca-certificates on startup, but the components didn’t care.
  • Was that mitigated (for those components) by the introduction of REQUESTS_CA_BUNDLE?
• Similar for the Python runner, see last topic.

Is it still necessary for me to build my own patched images?

This might be handled in Custom Certificates - SeaTable Admin Manual implicitly (mapping the CA store plus REQUESTS_CA_BUNDLE to tell thirdparty components), but I just wanted to make 100% sure before upgrading.

[abaer]

Hello everyone,

I think i figured it out: A cautious “yes“: In Seatable Server, I didn’t need to patch the following third party CA collections. I guess that REQUEST_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt overrides their individual CAs.

These are the afflicted third party components:

• /opt/seatable/seatable-server-latest/dtable-web/thirdpart/certifi/cacert.pem
• /opt/seatable/seatable-server-latest/dtable-web/thirdpart/aliyunsdkcore/vendored/requests/packages/certifi/cacert.pem
• /opt/seatable/seatable-server-latest/dtable-web/thirdpart/botocore/cacert.pem

Not knowing what they exactly do, I could only test my one use case (Export table as Excel). Assuming that the issue has been solved is part educated guess, part hope - I hope that someone can verify.

EDIT (for those who face the same “my-own-CA“-challenges):

I just discovered two more areas which were affected by missing corporate CAs in Seatable:

• “Dashboard“-Pages in Universal Apps would neither save nor display anything, they are just white.
• Exporting Universal Apps will lack a lot of data, mainly dashboard pages and assets on them (pictures).

The bad aspect: the second issue was present even on our 5.3.12 production server, where I applied the 3 patches from above. Obviously, some other component was affected, too.

The good aspect: Apart from the fact that I could fix our production server, this was done by setting REQUEST_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt in the seatable-server container. And, of cource, the CA bundle needs to contain the custom CA as described in Custom Certificates - SeaTable Admin Manual

This all applies to Seatable 5.3.12 at the moment. I’ll update soon to 6.0.10 without patching the image as described, and answer my own question here if REQUEST_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt takes care of all custom CA issues.