apache/2.2.22: https://<VirtualHost> ja, aber Zugriff auf https://<public ipadress> unterbinden

Hinweis: In dem Thema apache/2.2.22: https://<VirtualHost> ja, aber Zugriff auf https://<public ipadress> unterbinden gibt es 4 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • apache/2.2.22: https://<VirtualHost> ja, aber Zugriff auf https://<public ipadress> unterbinden

    Hallo,

    ich habe einen Apache in Version 2.2.22 am Laufen und so aufgesetzt, dass er ganz normal auf http (also port 80) bei ipAdresse und virtual host reagiert.
    Nun wollte ich den Server so erweitern, dass auch https (port 443) unterstützt wird.
    Dies ist mir soweit gelungen, dass die entsprechenden Zertifikate vorliegen und auch für domain1 und domain2 übertragen werden und somit der Zugriff auf die entsprechenden Seiten funktioniert.

    Was mich jetzt noch stört ist, dass wenn man einen Zugriff auf meine öffentliche ipAdresse https://<xxx.xxx.xxx.xxx> macht, im Browser z.B. Firefox eine Fehlermeldung angezeigt wird dass das übertragene Zertifikat nicht passt und nur für die Domains domain1, domain2, ... ausgestellt wurde.

    Dies würde ich nun gerne noch unterbinden, dass das Zertifikat in diesem Fall bei Zugriff per ipAdresse übertragen wird und somit auch die Information über die gehosteten virtuellen Adressen.

    Zusammengefasst:
    http://<ipAdresse> - ja
    https://<ipAdresse> - soll stumm bleiben
    http:// bzw https://<virt.Server> - soll funktionieren

    ps: ich habe auch bereits mit 'SSLStrictSNIVHostCheck off/on' experimentiert, jedoch ohne den entsprechenden Erfolg.

    Gedanken: Ich denke, dass ich mit einer passenden Konfiguration einer default-ssl Einstellung, wie versucht, für den Apache auch nicht unbedingt weiterkommen werde, da das Zertifikat bereits im Vorfeld übertragen wird bevor irgendwelche Konfigurationen wie redirects zum tragen kommen ... ich andererseits für eine ipAdresse kein Zertifikat ausgestellt bekomme und diese sich zudem ja alle 24h ändert.

    Also: wie bekomme ich mein https Zugriff auf die ip Adresse Stumm und behalte gleichzeitig die Anfragen für die virtuellen hosts am Laufen.

    Grüße & Danke
    ?(
    Bj.69, SW-Ing., Studium E-Technik, dabei seit Linux mit Disketten verfügbar war. DLD->(redhat)->Suse/(ubuntu). Linux auf Desktop, Laptops und VMs

    Für den Inhalt des Beitrages 117682 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Gar nicht.
    Certs sind an Domainnamen gebunden.

    Und ein Cert für eine IP Adresse wirst du sicher nicht kriegen.
    Dazu müsste dein Provider dir eine feste IP, die selbst schon kostest, falls sie überhaupt angeboten wird.
    Ich selbst habe so ein Cert noch nie gesehen, obwohl manche munkeln, so etwas könne man machen. (Ich bezweifle das eher)
    Jedenfalls wäre ein solches Cert wohl richtig teuer.

    Schalte einfach den Webserver für die IP-Adresse aus.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 117689 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • @Berichtigung, danke erst mal soweit.


    Vielleicht liest das ja noch jemand die nächsten Tage und hat mir noch den einen oder anderen Tip, evtl kommen apache-ich-https auch gar nicht zueinander, denn was mich stört sind 2 Punkte.


    1) unter http/port 80 kann ich mir virtuelle hosts einrichten und behalte das Wissen über die domains bei mir, bzw. demjenigen dem ich es mitteile. Sobald ich den Apache für https/port 443 einrichte posaunt mir der Indianer das hinaus sobald man per https://<ipadresse> darauf zugreift. Direkt sichtbar im Browser und evtl. nicht zu unterbinden (?)


    2) Scheint das Cert selbst zu sein, oder die Weise wie ich es generiert habe. In meinem Fall per acme.sh script, das auch dafür sorgen sollte diese rechtzeitig bei Ablauf zu erneuern. Hierbei habe ich 3 domains angegeben, für 2 domains wurden die Daten *.cer, *.ket etc auf Platte geschrieben, warum eine Domain fehlt muss ich noch ergründen. Auf jeden Fall scheinen in jedem Cert die Informationen über alle 3 domains enthalten zu sein - oder ist das nur mein Eindruck? Ich schließe zumindest darauf, da mir der Indianer bei Zugriff auf https://<ipadresse> ein solches Zertifikat liefert und darin alle 3 domains aufgeführt sind.



    Meine Haustüre sagt ja auch nicht, der Schlüssel passt hier nicht, aber es gibt noch die 3 anderen Türen wo er passt. 8o


    ?(
    Bj.69, SW-Ing., Studium E-Technik, dabei seit Linux mit Disketten verfügbar war. DLD->(redhat)->Suse/(ubuntu). Linux auf Desktop, Laptops und VMs

    Für den Inhalt des Beitrages 117723 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • TuxSv748 schrieb:

    ...Sobald ich den Apache für https/port 443 einrichte posaunt mir der Indianer das hinaus sobald man per https://<ipadresse> darauf zugreift....
    Dann solltest du einfach deinen Apache sauber konfigurieren. Wenn du deine Konfig nicht mitteilst, kann man auch nicht helfen.

    Und statt "posaunt hinaus" würden wir lieber eine Kopie der Ausgabe dieser Posaunen lesen.


    TuxSv748 schrieb:

    Scheint das Cert selbst zu sein, oder die Weise wie ich es generiert habe. In meinem Fall per acme.sh script, das auch dafür sorgen sollte diese rechtzeitig bei Ablauf zu erneuern.
    Welches acme.sh? (Es gibt Tonnen davon.)


    TuxSv748 schrieb:

    Hierbei habe ich 3 domains angegeben, für 2 domains wurden die Daten *.cer, *.ket etc auf Platte geschrieben, warum eine Domain fehlt muss ich noch ergründen. Auf jeden Fall scheinen in jedem Cert die Informationen über alle 3 domains enthalten zu sein - oder ist das nur mein Eindruck? Ich schließe zumindest darauf, da mir der Indianer bei Zugriff auf https://<ipadresse> ein solches Zertifikat liefert und darin alle 3 domains aufgeführt sind.
    Meine Haustüre sagt ja auch nicht, der Schlüssel passt hier nicht, aber es gibt noch die 3 anderen Türen wo er passt.
    Welche drei Domains? Poste ein ls -Al /etc/letsencrypt
    acme.sh wirst du wohl mit Letsencrypt verwenden.
    Dort gibt es keine Certs für IP- Adressen. Ganz sicher nicht.

    Und nein: Die Certs verschiedener Domains sind verschieden. Sie wissen nichts voneinander.
    Was dein Apache liefert, legt deine (hier fehlende) Konfig fest. Sonst niemand.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 117724 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • GitHub - Neilpang/acme.sh: A pure Unix shell script implementing ACME client protocol

    mir ist noch eingefallen, dass ich im Rahmen der Installation dieses script mehrmals aufgerufen habe mit unterschiedlichen Optionen, weil es nicht gleich beim ersten Mal funktioniert hat.
    Darunter mit der Option '--apache -d <domain1> -d <domain2> -d <domain3>'
    Später mit u.a. mit der option(en) '-d <domain1> -w /etc/apache2/ssl/<domain1> -d <domain2> -w /etc/apache2/ssl/<domain2> -d <domain3> -w /etc/apache2/ssl/<domain3>', und die jeweils in der VirtualHost Section händisch eingetragen.

    /etc/letsencrypt
    existiert nicht, die Daten wurden vom script anderweitig abgelegt, bzw. von mir der Pfad /etc/apache2/ssl/<domain>/. angegeben zum Erzeugen


    Ich geh momentan davon aus, dass jeder Aufruf weitere Certs hinzugefügt hat und insb. der erste Aufruf mit --apache Option noch weiterhin aktiv ist und durch die weiteren Aufrufe des Scripts nicht deaktiviert wurde. Das würde erklären, dass ich bei Aufruf https://<ipadresse> das Cerf mit allen 3 domains geliefert bekomme.

    z.B. eine VirtualHost Section, meine eigentliche domain ist durch <***> ersetzt

    Quellcode

    1. <IfModule mod_ssl.c>
    2. <VirtualHost *:443>
    3. ServerName <***>
    4. ServerAdmin webadmin@localhost
    5. DocumentRoot /var/www/virtual/<***>
    6. <Directory />
    7. Options FollowSymLinks
    8. AllowOverride None
    9. </Directory>
    10. <Directory /var/www/virtual/<***>/>
    11. Options Indexes FollowSymLinks MultiViews
    12. AllowOverride None
    13. Order allow,deny
    14. allow from all
    15. </Directory>
    16. ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    17. <Directory "/usr/lib/cgi-bin">
    18. AllowOverride None
    19. Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    20. Order allow,deny
    21. Allow from all
    22. </Directory>
    23. SSLEngine On
    24. SSLCACertificateFile /etc/apache2/ssl/<***>/ca.cer
    25. SSLCertificateFile /etc/apache2/ssl/<***>/<***>.cer
    26. SSLCertificateKeyFile /etc/apache2/ssl/<***>/<***>.key
    27. ErrorLog ${APACHE_LOG_DIR}/<***>.ssl.error.log
    28. # Possible values include: debug, info, notice, warn, error, crit,
    29. # alert, emerg.
    30. LogLevel warn
    31. CustomLog ${APACHE_LOG_DIR}/<***>.ssl.access.log combined
    32. </VirtualHost>
    33. </IfModule>
    Alles anzeigen
    Ok, ich denke ich muss den Server erst mal putzen, d.h. versuchen insb. das per --apache Option erzeugte Cert/Daten mit den 3 domains wieder loszuwerden, dann dürfte sich das ein oder andere Problem damit schon erledigt haben.

    (ps: scheint nicht beschrieben zu sein wie ich zuviel beantragte Certs durch mehrfache acme.sh Aufrufe wieder aus dem System entfernen kann)

    :)
    Bj.69, SW-Ing., Studium E-Technik, dabei seit Linux mit Disketten verfügbar war. DLD->(redhat)->Suse/(ubuntu). Linux auf Desktop, Laptops und VMs

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 117733 haftet ausdrücklich der jeweilige Autor: TuxSv748

www.cyberport.de