Allow importing own CA certificates prior to starting containers

[LuFlo]

Basically the whole issue is described here: #717

In short: It should be "officially" possible to use own certificates via a reverse proxy for the apache container by installing a CA file inside the mastercontainer. A bonus would be, if one could configure ssl certificates without using a reverse proxy, but this would mean more work I guess.

In the discussion mentioned above, I also posted a workaround. This could be a starting point for implementing this feature. I imagine that you could copy the CA file in a designated folder in the config volume of nextcloud-aio-mastercontainer. An amazing feature would be to copy the certificated via the web interface but let's make small steps 😅

What do you think about it?

[szaimen]

I will not work on this but PRs are welcome!

[dantefromhell]

Would be very helpful as it's fairly easy with some testing to blow through the rate limiting of ZeroSSL/ Let's Encrypt.

[szaimen]

What about an option for skipping the domain validation process. Would that cover your suitcase?

[szaimen]

So basically these lines could be skipped then:

all-in-one/php/src/Data/ConfigurationManager.php

Lines 201 to 239 in 2d9a1af

	$dnsRecordIP = gethostbyname($domain);
	// Validate IP
	if(!filter_var($dnsRecordIP, FILTER_VALIDATE_IP)) {
	throw new InvalidSettingConfigurationException("DNS config is not set for this domain or the domain is not a valid domain! (It was found to be set to '" . $dnsRecordIP . "')");
	}
	// Check if port 443 is open
	$connection = @fsockopen($domain, 443, $errno, $errstr, 10);
	if ($connection) {
	fclose($connection);
	} else {
	throw new InvalidSettingConfigurationException("The server is not reachable on Port 443. You can verify this e.g. with 'https://portchecker.co/' by entering your domain there as ip-address and port 443 as port.");
	}
	// Get Instance ID
	$instanceID = $this->GetSecret('INSTANCE_ID');
	// set protocol
	$port = $this->GetApachePort();
	if ($port !== '443') {
	$protocol = 'https://';
	} else {
	$protocol = 'http://';
	}
	// Check if response is correct
	$ch = curl_init();
	$testUrl = $protocol . $domain . ':443';
	curl_setopt($ch, CURLOPT_URL, $testUrl);
	curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
	$response = (string)curl_exec($ch);
	# Get rid of trailing \n
	$response = str_replace("\n", "", $response);
	if ($response !== $instanceID) {
	error_log('The response of the connection attempt to "' . $testUrl . '" was: ' . $response);
	throw new InvalidSettingConfigurationException("Domain does not point to this server or the reverse proxy is not configured correctly. See the mastercontainer logs for more details. ('sudo docker logs -f nextcloud-aio-mastercontainer')");
	}

[szaimen]

Or maybe would mounting /usr/share/ca-certificates from the host into the same place inside the mastercontainer make it work already?
I could document this then...

[dantefromhell]

From what I could gather so far, certs get auto-requested by Caddy twice

• one in the nextcloud-aio-mastercontainer container if you connect to port :8443
• one in the nextcloud-aio-apachage container

correct?

So when trying to use a custom certificate (possibly incl. chain) + private key those would need to be inserted into both containers before startup, no?

[LuFlo]

Or maybe would mounting /usr/share/ca-certificates from the host into the same place inside the mastercontainer make it work already? I could document this then...

Sorry for the late reply. Well there is another issue: I realized that we need to copy the CA into the talk container as well, otherwise the talk container does not accept the nextcloud container. Interestingly there is a checkbox in the Talk settings UI do disable SSL validation, but I think this only disables the validation of the signaling server but not the other way around. The thing is, the talk container does not seem to have a volume, so I had to paste the CA into a file manually. I guess it has to be done after every update though...

[szaimen]

So this is one of the reasons why I still think that allowing self-signed certificates is a bad idea since it comes with many unexpected side effects...

[szaimen]

This could be an alternative for self-signed certificates: #878

[szaimen]

I am honest to you: I do not want to support self-signed certificates so this will not be added.

There are enough possibilities to get a valid certificate for AIO and there is now also a way to disable the domain validation.

[szaimen]

It is since a while possible to simply skip the domain validation which should resolve this.

[szaimen]

And it is even possible to mount a ca certificate into the Nextcloud container. E.g. for LDAPS