Ja, das liegt daran, daß pyLoad beim Einrichten des SSL-Kontexts (irgendwo in der WSGI-Implementierung in modules/lib) gar keine Möglichkeit vorsieht, ein Kennwort für den privaten Schlüssel ein- oder anzugeben.
Nun könnte man ja auf die Idee kommen, den Schlüssel einfach als "unencrypted copy" für den Start von pyLoad zu speichern (hoffentlich nur irgendwo im tmpfs, die Leute kommen ja auf die merkwürdigsten Ideen), aber selbst das muß eigentlich nicht sein, wenn man anstelle der Schlüsseldatei einen FIFO (kann man auch mit "mknod <dateiname> p" einrichten, wenn es kein mkfifo geben sollte) benutzt, in den einerseits mit openssl (natürlich bei jedem Start von pyLoad) der unverschlüsselte Key geschrieben wird und aus dem dann - quasi "auf der anderen Seite" - der Python-Code ihn lesen kann. Da dort ja nicht von stdin gelesen wird, ist das Verwenden von Pipes im Shell-Code außen herum ja nicht möglich.
Die saubere Lösung wäre das Hinzufügen einer Callback-Funktion zum Webserver-Code von pyLoad (set_passwd_cb heißt die Methode für den SSL-Kontext in pyopenssl), die dann beim Lesen des verschlüsselten Keys das Kennwort direkt bereitstellt ... sind - grob geschätzt - 10 Zeilen Python, die man ändern müßte (EDIT: und als Änderungsvorschlag im Upstream einreichen könnte, wenn man es ähnlich wie Apache2 mit dem PassphraseDialog-Parameter macht).
- - - Aktualisiert - - -
Wobei auch pyLoad wieder ein Paradebeispiel dafür ist, daß man die Verwender der OpenSSL-Libraries auch mal zu ihrem Glück zwingen muß ... wenn da im Prinzip auch eine SSLv2- oder SSLv3-Verbindung
möglich wäre, dann kann nur die bereitgestellte Library das noch irgendwie verhindern. Da gehört heutzutage eben TLSv1_2_METHOD hin und gut ist's ... wenn jemand unbedingt einen uralten Browser zur Verwaltung benutzen will, muß er eben auch eine uralte pyLoad-Version benutzen oder selbst Hand anlegen.
Dann kann man auch gleich noch die Unterstützung für verschlüsselte "private keys" hinzufügen, denn das ist nichts weiter als eine zusätzliche Callback-Funktion in diesem Cherry-irgendwas-Server, die ein externes Programm aufruft, dessen stdout dann die zu verwendende Passphrase liefert beim Aufruf. Solche Passphrase-Callbacks hat heutzutage jede halbwegs ernst zu nehmende Software, die mit verschlüsselten Daten umgehen muß oder will - die einfach von vorneherein unverschlüsselt zu speichern, nur weil man ein paar wenige Zeilen sparen will, ist einfach nicht mehr zeitgemäß.