Also, das Problem habe ich nicht gelöst, sondern umgangen:
Der Cloudserver hat nun ein Zertifikat mit 2 Namen, die Namen werden von der Opnsense auf die Netzwerkkarten in den jeweiligen Netzen geroutet (per Überbrückung im UnboundDNS).
Bekannt ist aber nur ein Name, der für die Benutzer aus dem grünen Netz eigentlich falsch ist. Damit die aber auch Dateien hochladen können, gibt es folgende Erweiterung in der .htaccess-Datei der Nextcloud. Sie wurde unter „#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####“ geschrieben in der Hoffnung, dass Nextcloud-Updates diesen Teil dann behalten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^10\.20
RewriteCond %{REMOTE_ADDR} !^10\.20\.0\.0$
RewriteCond %{REMOTE_ADDR} !^10\.20\.255\.255$
RewriteCond %{HTTP_HOST} ^cloud\.intern\.schuldomain\.de$ [NC]
RewriteRule ^(.*)$ https://cloudserver.intern.schuldomain.de/nc/ [R=301,L]
# Durch das L in der eckigen Klammer wird die Regel beendet, es folgt die nächste
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^(.*)$ https://cloud\.intern\.schuldomain\.de/$1 [R=301,L]
</IfModule>
Was weiterhin nicht funktioniert, ist das Einfügen von Bildern in ein Collabora Dokument, sofern man sie direkt hochlädt. Zuerst hochladen und aus der Cloud einfügen, klappt. Der Grund hierfür ist, dass ich keine passende Anleitung zum Reverse Proxy für Collabora gefunden habe. Alle Anleitungen benutzen die Ports 80 und 443, die auf meinem „echten“ Server (keine Docker) schon belegt sind. Somit greifen die Clients direkt auf Collabora zu und aus dem grünen Netz entsteht dasselbe Problem wie zuvor mit der Nextcloud, nur dass ich bei Collabora nicht 2 Ansprechwege habe. (Das ist aber verschmerzbar, und wenn irgendwann das MEP-WLAN eingebaut wurde, wird die Netzstruktur reorganisiert.)
So, dass ist jetzt ein Monolog. Wenn ihn niemand braucht, kann den ganzen Thread gerne ein Admin löschen. Nur offen stehen lassen wollte ich die Frage nicht.