BBB ist ein komplexes System mit vielen Teilsystemen, die auf dem BBB-Server untereinander über mehrere Netzwerkschnittstellen kommunizieren. Es werden mehrere Datenbanken eingesetzt (mongodb, redis, postgres), Teile der Software sind in JavaScript geschrieben. Präsentationen werden seitenweise mit Hilfe von soffice.bin (Open/Libre-Office) in SVG-Grafiken konvertiert.
Architektur siehe → https://docs.bigbluebutton.org/2.2/architecture.html

Links zu den Anleitungen, die hier verwendet wurden:

• (1) Installation BBB → https://github.com/bigbluebutton/bbb-install
• (2) Erzeugen eines RootCA-Zertifikates + Server-Zertifikat → https://mherbst.de/de/articles-internet/erstellungeigenersslzertifikate/
• (3) BBB komplett auf https umstellen → https://docs.bigbluebutton.org/2.2/install.html#configure-ssl-on-your-bigbluebutton-server

Für einen schnellen Test kann man mit Hilfe der Anleitung (1) einen BBB-Server aufsetzen, der jedoch nur über http läuft und man somit weder Mikro noch Webcam verwenden kann, da sowohl Firefox als auch Chrome für diese Freigaben https erfordern:

# wget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | bash -s -- -w -v xenial-22 -a -w

Ebensowenig erlauben die Browser an Desktop-Clients keine Mikro- und Webcam-Freigaben für „self-signed“ Zertifikate, selbst wenn man diese extra importiert. An einem Android-Device war es jedoch möglich mit den „self-signed“ Zertifikaten Mikro und Webcam freizugeben.
Da das Testsystem im grünen Netz die interne URL bbb.linuxmuster-net.lokal hatte, war das Installieren eines öffentlich gültigem Zertifikates von Let's Encrypt auch nicht möglich.
Als Lösung habe ich dann folgende Schritte durchgeführt:

• Erzeugen einer Zertifizierungsstelle, das Stammzertifikat (myRoot.crt), die Root-CA
• Erzeugen eines Webserver-Zertifikates (bbb.crt) mit dieser Root-CA
• Import der Root-CA in die Browser-CAs von Firefox, Chrome und ins Android-Device
• Import der Root-CA in die ssl-Zertifikate des BBB-Server
• Eintragen des Websever-Zertifikates beim Webserver nginx
• Installation von BBB mit der URL bbb.linuxmuster-net.lokal
• Installation von Greenlight und Import der Root-CA in den Docker-Container von Greenlight
• Bereitstellen der Root-CA für die JavaScript-Laufzeitumgebung im BBB-Server

Das ganze stellte sich letztendlich als sehr komplex heraus, ggf. sind deshalb nicht alle nachfolgend aufgeführten Schritte unbedingt notwendig.

Als Basissystem einen Ubuntu-Server 16.04 (Name „bbb“) mit 4 GB RAM und 3 Prozessoren (der Testserver war eine VM in VirtualBox). Weniger Hardware geht nicht, sonst bricht die Installation ab. Den Server dann mit Namen „bbb“ in die Workstations aufnehmen. Bei meiner Testumgebung hatte der BBB-Server die IP 10.16.1.3 und die URL bbb.linuxmuster-net.lokal und befindet sich im grünen Netz.

Um auch die korrekte Namensauflösung vom blauen Netz zu gewährleisten trägt man den BBB-Server mit seiner IP und URL in die host-Liste der Firewall IPFire ein. Als DNS-Server in Blau muss dann beim DHCP der Firewall die blaue IP der Firewall stehen.
Oder man verwendet besser den LMN-Server selbst als DNS-Server beim DHCP und erstellt eine Firewall-Regel für den Zugriff über UDP, Port 53 von Blau zum LMN-Server.

Die Zertifikatserstellung erfolgt mit dem Kommandozeilentool openssl nach der Anleitung (2) am BBB-Server. Openssl verwendet dabei mehrere Dateitypen:

• .key - Private Schlüssel
• .crt - Zertifikate, diese haben manchmal auch die Endung .pem oder .cert, was man aber aus Kompatibilitätsgründen vermeiden sollte
• .csr - Zertifikatsanfrage - steuert eine Zertifikatserstellung
• .cnf - Konfigurationsdateien

Als Speicherort wird hier das Verzeichnis /etc/ssl/lmn/ verwendet. Da nur ein Testsystem aufgebaut wird, werden Zugriffsrechte für die privaten Schlüssel nicht gesetzt.

 # mkdir /etc/ssl/lmn
 # cd /etc/ssl/lmn

Privaten Schlüssel des Stammzertifikates und Stammzertifikat selbst erzeugen:

 # openssl genrsa -out myRoot.key 2048
 # openssl req -x509 -new -nodes -key myRoot.key -sha256 -days 3650 -out myRoot.crt

Konfigurationsdatei bbb.csr.cnf anlegen:

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[dn]
C=DE
ST=BW
L=Karlsruhe
O=linuxmuster
emailAddress=root@linuxmuster-net.lokal
CN = bbb.linuxmuster-net.lokal

Weitere Konfigurationsdatei bbb.ext.cnf anlegen:

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = bbb.linuxmuster-net.lokal
DNS.2 = 10.16.1.3
DNS.3 = bbb

Eine IP als Common-Name des Zertifikates wird von den Browsern nicht akzeptiert, kann ggf. weggelassen werden.

Zertifikatsanfrage, privaten Schlüssel des Webserver-Zertifikates erzeugen und damit Webserver-Zertifikat erstellen:

# openssl req -new -sha256 -nodes -out bbb.csr -newkey rsa:2048 -keyout bbb.key -config bbb.csr.cnf
# openssl x509 -req -in bbb.csr -CA myRoot.crt -CAkey myRoot.key -CAcreateserial -extfile bbb.ext.cnf -out bbb.crt -days 3650 -sha256

Die Firewall OPNsense und pfSense bieten ebenfalls auf ihrem Web-Frontend eine Zertifikatserstellung für Root und Server-Zertifikate an. Dies ist eine deutliche Vereinfachung gegenüber dem Tool openssl. Bei pfSense waren die Zertifikate verwendbar, bei OPNsense leider nicht.

 # mkdir /usr/share/ca-certificates/lmn
 # cp /etc/ssl/lmn/myRoot.crt /usr/share/ca-certificates/lmn/
 # dpkg-reconfigure ca-certificates

Dieser Schritt ist notwendig, da BBB auch für die interne Kommunikation der Komponenten auf https aufsetzt, ansonsten findet der BBB-Server sich teilweise „selbst“ nicht.

Firefox und Chrome haben programminterne Zertifikatslisten, somit muss man einen Import des Stamm-Zertifikates myRoot.crt durchführen. Dies geht in beiden Browsern über:
Einstellungen –> Datenschutz und Sicherheit –> Zertifikate –> …
Ein Import des Server-Zertifikates bbb.crt oder eine Bestätigung des Server-Zertifikates ist nicht notwendig, da es ja nicht self-signed ist. Firefox zeigt nur den Hinweis, dass das Zertifikat bbb.crt von einer „nicht standardmäßigen Zertifizierungsstelle“ zertifiziert ist.

Bei einem Android-Device werden die Zertifikate systemweit installiert. Diese sicherheitsrelevante Aktion muss mit Passworteingabe bestätigt werden. Das Stammzertifikat myRoot.crt auf das Device übertragen, öffen und einen Namen vergeben. Danach verwendet Chrome das Stammzertifikat und stuft die Verbindung zum BBB-Server ohne Nachfrage als sicher ein.

siehe → https://support.citrix.com/article/CTX228877

Bei der Installation nach Anleitung (1) wird das Script bbb-install.sh abgearbeitet, das mehrere hundert Pakete installiert und ca. 20 Minuten dauerte. Dabei wird u.a. der Webserver nginx mitinstalliert.

Option „-qO-“ (Großbuchstabe O) bedeutet: quiet + Output-document=<standard output>.

# wget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | bash -s -- -w -v xenial-22 -s bbb.linuxmuster-net.lokal -a -w

Danach kann man im Browser die URL „http://bbb.linuxmuster-net.lokal“ aufrufen und eine BBB-Sitzung starten, jedoch ohne Mikro- und Webcam-Freigabe. Danach weiter mit Punkt 5.).

Selbst erstellte Zertifikate für das Install-Script mit den passenden Dateinamen kopieren:

# mkdir -p /local/certs
# cp /etc/ssl/lmn/bbb.crt /local/certs/fullchain.pem
# cp /etc/ssl/lmn/bbb.key /local/certs/privkey.pem

Install-Script aufrufen mit Installation Greenlight (-g), ohne Let's-encrypt (-d):

# wget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | bash -s -- -w -v xenial-22 -s bbb.linuxmuster-net.lokal -e root@linuxmuster-net.lokal -d -g -w

Die folgenden Punkte 5.) und 6.) können nun übersprungen werden, weiter mit Punkt 7.)

Nach Anleitung (3) müssen mehrere Konfigurationen angepasst werden.

Da der BBB-Server ausschließlich per https antworten sollte habe ich den Symlink „@default“ gelöscht:

 # rm /etc/nginx/sites-enabled/default

Dann die Datei /etc/nginx/sites-available/bigbluebutton bei den ersten Zeilen editieren:

server {
   listen 80;
   listen [::]:80;
   return 301 https://bbb.linuxmuster-net.lokal;
}

server {
   listen 443 ssl;
   listen [::]:443 ssl;
   server_name bbb.linuxmuster-net.lokal;
   
   ssl_certificate /etc/ssl/lmn/bbb.crt;
   ssl_certificate_key /etc/ssl/lmn/bbb.key;
   ssl_session_cache shared:SSL:10m;
   ssl_session_timeout 10m;
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_ciphers "ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS:!AES256";
   ssl_prefer_server_ciphers on;
   ssl_dhparam /etc/ssl/lmn/dhp-4096.pem;

   access_log /var/log/nginx/bigbluebutton.access.log;
   
   ...

Achtung: Jede Zeile mit Semicolon abschließen!
Und noch die Hilfs-Datei für die https-Verschlüsselung erzeugen (dauert ggf. sehr lange, > 10 Minuten):

 # openssl dhparam -out /etc/ssl/lmn/dhp-4096.pem 4096

Nach Anleitung (3) vorgehen → https://docs.bigbluebutton.org/2.2/install.html#configure-ssl-on-your-bigbluebutton-server

Alle 7 anzupassende Dateien ggf. vorher sichern:

• /etc/bigbluebutton/nginx/sip.nginx
• /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties
• /usr/share/red5/webapps/screenshare/WEB-INF/screenshare.properties
• /var/www/bigbluebutton/client/conf/config.xml
• /usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml
• /usr/local/bigbluebutton/core/scripts/bigbluebutton.yml
• /var/lib/tomcat7/webapps/demo/bbb_api_conf.jsp

Abschließend BBB und nginx neu starten:

 # service nginx restart
 # bbb-conf --restart

Nach den obigen Schritten 4a. + 5. Greenlight nachträglich durch der Option „-g“ installieren:

# wget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | bash -s -- -w -v xenial-22 -s bbb.linuxmuster-net.lokal -g -w
# apt-get purge bbb-demo

Jetzt Greenlight aufrufen mit der URL „https://bbb.linuxmuster-net.lokal“

Problem:
Der Docker-Container enthält nicht das oben erstellte ssl-Stammzertifikat und verbindet sich somit nicht über https mit BigBlueButton.
Greenlight zeigt die Fehlermeldung, „Serverfehler - BigBlueButton Endpunkt und Geheimnis ungültig“.

Lösung:
Das Stammzertifikat /etc/ssl/lmn/myRoot.crt in den Dockercontainer integrieren. Zunächst die <Container-ID> ermitteln:

# docker ps

CONTAINER ID       IMAGE
834a12b22dc7       bigbluebutton/greenlight:v2
...

ergibt als <Container-ID> für Greenlight z.B. 834a12b22dc7, die in den beiden nächsten Befehlen eingesetzt werden muss:

# docker cp /etc/ssl/lmn/myRoot.crt <Container-ID>:/usr/local/share/ca-certificates/myRoot.crt
# docker exec -it <Container-ID> update-ca-certificates
# cd ~/greenlight
# docker-compose restart

Überprüfen:

# docker run --rm --env-file .env bigbluebutton/greenlight:v2 bundle exec rake conf:check

ergibt weiterhin die Fehlermeldung: „ … Certificate verify failed (unable to get local issuer certificate)“,
aber die Verbindung von Greenlight zu BBB funktionierte trotzdem.

Änderungen in den Container integrieren:

# cd ~/greenlight
# docker-compose stop
# docker commit 834a12b22dc7 bigbluebutton/greenlight:v2
# docker-compose up -d

Einen Standard-Admin-Account am BBB-Server anlegen:

# cd ~/greenlight
# docker exec greenlight-v2 bundle exec rake admin:create

Erzeugt den vorkonfigurieten Zugang „admin@example.com“ und Kennwort „administrator“ - damit dann im Web-Frontend anmelden.

Problem:
Bei einer Installation nur mit http werden die Präsentationsfolien angezeigt, nach Umstellung auf https leider nicht mehr - Zertifikatsproblem bei 'node', der JavaScript Laufzeitumgebung von BBB.
Lösung:
In der Datei /usr/share/meteor/bundle/systemd_start.sh den ENVIRONMENT_TYPE ändern und eine neue Umgebungsvariable zu unserem Stammzertifikat von oben setzen:

...
ENVIRONMENT_TYPE=production
...
cd /usr/share/meteor/bundle
export NODE_EXTRA_CA_CERTS=/etc/ssl/lmn/myRoot.crt
..

Nun BBB neu-starten.

# bbb-conf --restart

Siehe auch → https://github.com/bigbluebutton/bigbluebutton/issues/8984

Mit der URL „https://bbb.linuxmuster-net.lokal“ erreicht man nun Greenlight, kann sich registrieren, einloggen und ein Meeting starten:

• Greenlight funktioniert und verbindet sich mit BBB
• Echo-Test, Mikro+Webcam funktionieren
• Präsentationen erscheinen und können hochgeladen werden
• Whiteboard funktioniert
• Bildschirmfreigaben funktionieren
• Umfragen funktionieren
• öffentlicher Chat, geteilte Notizen funktionieren
• Breakouträume funktionierten (Dafür müssen einfache Teilnehmer vorhanden sein)
• Status setzen und Teilnehmer entfernen funktionierte

Zum Testen der Konfigurationen am BBB-Server und von https gibt es folgende Befehle:

 # nginx -t
 # bbb-conf --check
 # bbb-conf --status
 # wget https://bbb.linuxmuster-net.lokal/default.pdf 

Zusätzlich kann man auf dem BBB-Server auch einen Speedtest installieren → Speedtest LibreSpeed

Tritt sporadisch beim Echotest auf, insbesondere bei virtualisierten BBB und hinter einer Firewall.
Mögliche Ursachen:

• Freeswitch, das System, das die Audio-Übertragung managed, benötigt einen echten Zeitgeber-RTC, keinen virtualisierten. Bei Bare-Metal-Installationen tritt der Fehler nach Berichten nicht auf.
• UDP-Pakete werden von der Firewall blockiert. Dieser Pakettyp wird bei der Audioübertragung verwendet. Das Zulassen von UDP-Paketen zwischen Blau und Grün beseitigte die Fehlermeldung für Clients, die im blauen Netz waren.

Trat bei IPad mit Safari in Grün und Blau auf, Echotest funktionierte nicht, nur Zuhören funktionierte nicht. Stammzertifikat myRoot.crt war importiert.

Die Willkommensmeldung befindet sich in der Datei: /usr/share/bbb-web/WEB-INF/classes/bigbluebutton.properties

defaultWelcomeMessage= ...
defaultWelcomeMessageFooter= ...