Hallo,
in /etc/cron.d/univention-letsencrypt wird /usr/share/univention-letsencrypt/refresh-cert-cron aufgerufen. Das sollte auch manuell funktionieren.
hth,
Dirk Ahrnke
Danke Herr Ahrnke,
wie immer hilfreich und Wegweisend.
Leider bekomme ich noch einen Fehler, keine Ahnung warum 
Refreshing certificate for following domains:
xxx.de webmail.xxx.de webmeetings.xxx.de photo.xxx.de
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying photo.xxx.de...
Traceback (most recent call last):
File "/usr/share/univention-letsencrypt/acme_tiny.py", line 198, in <module>
main(sys.argv[1:])
File "/usr/share/univention-letsencrypt/acme_tiny.py", line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)
File "/usr/share/univention-letsencrypt/acme_tiny.py", line 123, in get_crt
wellknown_path, wellknown_url))
ValueError: Wrote file to /var/www/.well-known/acme-challenge/Enu05bnyseWfgnR-EoyMZUzLtzGntjWm-7oPO2mVqZM, but couldn't download http://photo.xxx.de/.well-known/acme-challenge/Enu05bnyseWfgnR-EoyMZUzLtzGntjWm-7oPO2mVqZM
root@ucs:~#
Sie ein bischen aus wie am beginn dieses Threats…
Port 80 ist offen und ich bin auf 4.2-1 errata133
Grüße Carmen
In der letzten Zeile versucht das Skript die gerade nach /var/www/.well-known/acme-challenge/ kopierte Datei über den Webserver vom Host photo.xxx.de zu holen. Das sieht für mich so aus, als wüsste der Server nicht, dass er sich selbst fragen muss. Also entweder DNS oder Apache-Vhost.
Wenn photo.xxx.de auf einem anderen Docroot als /var/www sitzt habe ich aber erstmal auch keine Idee. In Zeile 49 von /usr/share/univention-letsencrypt/refresh-cert st das Verzeichnis /var/www/.well-known/acme-challenge/ fest verdrahtet.
Danke Ihnen noch mal Herr Ahrnke,
komisch, dass es beim Anlegen vor einiger Zeit funktioniert hat und nun irgendwie nicht mehr.
Es ist richtig, photo.xxx.de ist auf einem anderen Rechner im Netzwerk und wurde als Weiterleitung eingerichtet.
Ich denke dass es Grundsätzlich nicht geht und photo einfach die erste Abfrage ist und es dort abbricht.
Was mir noch aufgefallen ist, wenn ich unter letsencrypt/domains die photo.xxx.de lösche müsste ja eigentlich der Fehler weg sein, die Domain wird trotzdem versucht zu validieren.
Habe jetzt mal auf 4.2-2 errata159 upgedatet, ändert auch nichts.
Noch eine Idee?
Viele Grüße Carmen
Hallo,
wenn ich das Python-Skript, was von den o.g. Skripten aufgerufen wird, richtig deute, wird der Refresh immer aus den Domains in der domain.csr (via openssl req -in /etc/univention/letsencrypt/domain.csr -noout -text) gelesen. Das CSR wird aber beim Refresh nicht neu erzeugt. Wahrscheinlich muß man hier wirklich setup-letsencrypt erneut aufrufen.
Zitat aus der Wiki:
When the list of domains in letsencrypt/domains changes and setup-letsencrypt is run again, a prompt asks for deleting the current csr-file and recreates it with the new UCR variable’s content.
hth,
Dirk Ahrnke
Danke Herr Ahrnke für Ihre großartige Aktivität hier…
Mit /usr/share/univention-letsencrypt/setup-letsencrypt bekomme ich genau den gleichen Fehler.
Da ich nun alle Domains entfernt habe und dann nach und nach hinzugefügt habe, liegt es wirklich an der photo.xxx.domain die auf dem anderen Server mit IP 192.168.1.2 der univention läuft unter 192.168.1.30.
Die Frage nach dem Löschauftrag kommt erst gar nicht.
Ist ja auch merkwürdig wenn ich die Domain lösche, dass die danach immer noch abgearbeitet werden soll, die müsste ja dann weg sein.
Viele Grüße Carmen
Hallo,
habe mir gestern die aktuelle Version 4.2 installiert und wollte anschließend den univention-letsencrypt Client nachschieben. Habe die Anleitung unter Cool Solutions befolgt. Leider funktioniert der Download über univention-install nicht, weil der Client nicht im Repository gefunden wird. Muss ich hier ein weiteres Repository einbinden ? Wenn ja, welches? Oder ist univention-letsencrypt aufgrund der aktuellen Fehlersituation aus dem Repository herausgenommen worden?
Gruß
Ralph
Vielen Dank! Und werde das nächste Mal die Augen auf machen 
Wie sind denn dieses Server aus dem Internet erreichbar? Unter “photo.xxx.de ist auf einem anderen Rechner im Netzwerk und wurde als Weiterleitung eingerichtet.” kann ich mir noch nichts vorstellen.
Welche CSRs liegen denn unter /etc/univention/letsencrypt/ ?
Danke Ihnen,
unter /etc/univention/letsencrypt/ ist folgendes zu finden:
account.key
domain.csr
domain.key
domains
chained.pem
intermediate.pem
post-refresh.d
setup.d
signed.crt
signed.crt_20170511-184648
signed.crt_20170511-184748
signed.crt_20170526-195452
signed.crt_20170601-033019
signed.crt_20170701-033023
signed.crt_20170906-225439
signed.crt_20170906-225519
signed.crt_20170906-225543
signed.crt_20170906-225844
signed.crt_20170907-122201
signed.crt_20170914-080005
chained.pem_20170511-184648
chained.pem_20170511-184748
chained.pem_20170526-195452
chained.pem_20170601-033019
chained.pem_20170701-033023
chained.pem_20170906-225439
chained.pem_20170906-225519
chained.pem_20170906-225543
chained.pem_20170906-225844
chained.pem_20170907-122201
chained.pem_20170914-080005
Ich habe noch mal die photo domain gelöscht und nach allen updates auf Errata 4.2.2-164 wirft es einen längere Liste mit Fehlern aus.
/usr/share/univention-letsencrypt/setup-letsencrypt
run-parts: executing /etc/univention/letsencrypt/setup.d//apache2
run-parts: executing /etc/univention/letsencrypt/setup.d//dovecot
run-parts: executing /etc/univention/letsencrypt/setup.d//postfix
Do 14. Sep 08:03:46 CEST 2017
Refreshing certificate for following domains:
domain1.de webmail.domain1.de webmeetings.domain1.de photo.domain1.de
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying photo.photo1.de...
Traceback (most recent call last):
File "/usr/share/univention-letsencrypt/acme_tiny.py", line 198, in <module>
main(sys.argv[1:])
File "/usr/share/univention-letsencrypt/acme_tiny.py", line 194, in main
signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)
File "/usr/share/univention-letsencrypt/acme_tiny.py", line 117, in get_crt
resp = urlopen(wellknown_url)
File "/usr/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib/python2.7/urllib2.py", line 437, in open
response = meth(req, response)
File "/usr/lib/python2.7/urllib2.py", line 550, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.7/urllib2.py", line 469, in error
result = self._call_chain(*args)
File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 656, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File "/usr/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/usr/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/usr/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/usr/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/usr/lib/python2.7/urllib2.py", line 1194, in do_open
h.request(req.get_method(), req.get_selector(), req.data, headers)
File "/usr/lib/python2.7/httplib.py", line 1039, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python2.7/httplib.py", line 1073, in _send_request
self.endheaders(body)
File "/usr/lib/python2.7/httplib.py", line 1035, in endheaders
self._send_output(message_body)
File "/usr/lib/python2.7/httplib.py", line 879, in _send_output
self.send(msg)
File "/usr/lib/python2.7/httplib.py", line 841, in send
self.connect()
File "/usr/lib/python2.7/httplib.py", line 1250, in connect
server_hostname=server_hostname)
File "/usr/lib/python2.7/ssl.py", line 350, in wrap_socket
_context=self)
File "/usr/lib/python2.7/ssl.py", line 566, in __init__
self.do_handshake()
File "/usr/lib/python2.7/ssl.py", line 796, in do_handshake
match_hostname(self.getpeercert(), self.server_hostname)
File "/usr/lib/python2.7/ssl.py", line 269, in match_hostname
% (hostname, ', '.join(map(repr, dnsnames))))
ssl.CertificateError: hostname 'photo.domain1.de' doesn't match either of 'domain1.de', 'webmail.domain1.de', 'webmeetings.domain1.de'
Hier mal die conf aus der /etc/apache2/sites-enabled
<VirtualHost *:80>
ServerName photo.domain1.de
Redirect / https://photo.domain1.de/photo/
</VirtualHost>
<VirtualHost *:443>
ServerName photo.domain1.de
SSLEngine on
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLCertificateFile /etc/univention/letsencrypt/signed.crt
SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
SSLCACertificateFile /etc/univention/letsencrypt/chained.pem
#SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
### To enable special log format for HTTPS-access
# LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" %p" combinedssl
# CustomLog /var/log/apache2/access.log combinedssl ## with port number
RedirectMatch ^/$ /photo/
ProxyPass /photo/ http://192.168.1.2/photo/
ProxyPassReverse /photo/ http://192.168.1.2/photo/
</VirtualHost>
Viele Grüße Carmen
Von den Redirects hab ich gerade einen Knoten im Hirn und daher erstmal keine wirkliche Lösung 
In der Port 80 Deklaration des Virtualhosts steht aber der generelle Redirect auf https.
Die Validierung will aber m.E: per http auf .well-known/acme-challenge/ für jede im Zertifikat eingetragene Domain zugreifen. Wenn es also Ziel ist, Lets Encrypt auch für die photo-Domain zu nutzen (und das nicht auf dem Zielhost selbst zu tun) , müsste man ./well-known vom Redirect ausnehmen.
Ansonsten fiel mir halt nur noch dieses auf:
Das kommt aus /usr/share/univention-letsencrypt/refresh-cert
date
echo "Refreshing certificate for following domains:"
cat "$DIR_LE/domains"
Da steht die photo-Domain also noch drin.
Danke Ihnen,
da es ohne die photo.domain1.de geht, habe ich die nun wieder hinzugefügt, daher kommen auch die Fehler wieder und meckert betreffend der Domain.
Was meinen Sie damit?
Wie oder was kann können wir da ausnehmen?
Dass ich den weg über den redirect via UCS gehe hat nur den Hintergrund, da es an dem DSL Anschluss mit einem Router leider nur Möglich ist einen Port 443 weiterzuleiten.
Viele Grüße aus dem Regen…C.
Ich versuch mich mal an einer Erklärung, bin aber nicht zu 100% sattelfest in diesem Gebiet.
Sie haben in der Sitedefinition vom photo-Virual für alle http-Zugriffe einen Redirect zu https://photo.domain1.de/photo/ eingerichtet. Dort liegt weder ein .well-known-Verzeichnis (wird u.a. von den letsecrypt-Skripten befüllt) noch hat die Validierung durch LetsEncrypt überhaupt die Chance, wie gefordert über http darauf zuzugreifen.
Entweder, man lebt ganz ohne diesen Redirect oder man nimmt nur “/photo” anstelle “/”, beides ist aber nicht so nutzerfreundlich. Kann sein, dass noch andere, etwas komplexere Redirect-Diektiven gehen, aber das überblicke ich im Moment nicht.
Sehr geehrter Herr Ahrnke,
ich habe mir noch mal Gedanken dazu gemacht und vielleicht eine einfachere Lösung gefunden.
Die Weiterleitung photo.domain1.de zeigt ja eine Anwendung auf einer Synology Diskstaion.
Die Diskstation selber bietet ein eigenes Letsencrypt Modul an.
In dem Fall würde es wohl ja reichen (hoffe ich denke nicht zu einfach), die Umleitung ohne den ganzen Zertifikat Kram zu machen und die Diskstation liefert dann das Zertifikat an den Browser.
Ist dass denkbar?
Hallo,
wir haben Ende letzter Woche die Let’s Encrypt integration als App im App Center veröffentlicht:
Die App steht für UCS 4.1 und 4.2 bereit, zur Migration von der Cool Solution gibt es Hinweise hier:
http://wiki.univention.com/index.php?title=Cool_Solution_-_Let's_Encrypt#Migrating_to_the_Let.27s_Encrypt_App
Ingo Steuwer
Hallo,
das könnte funktionieren, wenn für den Virtualhost sämtlicher http- und https-Traffic (also nicht nur “/photo” via Proxy an die Synology geschickt wird.
Viel Erfolg.
Dirk Ahrnke
Danke Herr Ahrnke @ahrnke und auch an Herr Steuwer @Steuwer,
ich habe die cool solution runtergeschmissen und die Version aus dem Appcenter installiert.
Kleiner test mit dem Komando funktiniert auch nur der Abruf des Zertifikats dann nicht mehr, gibt die gleichen Fehler aus wie vorher auch.
root@ucs:/var/log/univention# host -t A photo.domain.de
photo.xxxx.de has address 84.15x.19x.13x
Kurze Frage Herr Ahrnke @ahrnke,
gibt es einen Hinweis, wie ich dieses durchführen kann.
http- und https-Traffic (also nicht nur “/photo” via Proxy an die Synology geschickt wird.
Oder soll ich dazu einen neuen Post eröffnen…finde gerade nichts was dazu passt im Forum.
Viele Grüße Carmen
Das ist eine gute Idee, wir sind schon ein Stück vom ursprünglichen Thema entfernt. Vielleicht noch ein kurzer Anstoß: Mittlerweile glaube ich, dass in dieser Konstellation (wenn nur eine öffentliche IP verfügbar ist), es wahrscheinlich noch komplexer ist, das Zertifikat für “photo.domain.de” auf der Synology zu verwalten. Die Clients erwarten ja, dass das Zertifikat zum Hostnamen passt. SSL via Proxy erscheint mir nicht trivial, aber ich habe mich damit bislang auch nur am Rande befasst. Mein erster Ansatz wäre, einen “normalen” Virtualhost, ggf. mit eigenem Docroot auf dem UCS zu bauen und in dessen Konfiguration nur “/photo” zur Synology durchzureichen. Damit sollte man die Zertifikate erzeugt bekommen. Die Clients sollte man per Redirect weiter zu /photo schicken.
Hallo @ckraut,
ich habe mir gerade den Thread durchgelesen und für mich klingt es so als würden Sie versuchen mit der Lets Encrypt-App ein Zertifikat für einen anderen Server zu erstellen. Dies ist nicht möglich, da die App immer nur für den Server Zertifikate erstellen kann, auf dem sie läuft.
Dies hat den technischen Hintergrund, dass Lets Encrypt aus dem Internet heraus die Domain validiert, in dem Inhalt “x” in Datei “y” unter .well-known/acme-challenge abgelegt wird. Das kann nicht funktionieren, wenn die Domain auf einen anderen Server deutet, da die Datei dort einfach nicht vorhanden ist.
In älteren Versionen der App bestand außerdem das Problem, dass bei aktiviertem “force_https” in UCR, also der automatischen Weiterleitung von HTTP auf HTTPS durch Apache, die Validierung von Lets Encrypt nicht funktionierte. Dies ist jedoch seit der letzten Version der App gefixt.
Lets Encrypt hat angekündigt ab Januar 2018 auch Wildcard-Zertifikate (*.domain.de) zu unterstützen. Gegebenenfalls können Sie dann damit arbeiten.
Viele Grüße,
Valentin Heidelberger