Wie umgehen mit gemischtem Inhalt in eine website, die gesichert werden soll, wie https?

Baue ich eine Webseite auf server A (mit domain-Namen registriert), für die Menschen zu schaffen und führen Ihre "apps".
Diese "apps" sind eigentlich docker-Container läuft auf server B in den Behälter, dort lebt eine kleine web-app, die direkt zugegriffen werden kann wie:

http://IP_ADDR_OF_SERVER_B:PORT

HAFEN ist eine zufällige, große Zahl ein, welche Karten, um die docker-container.
Jetzt kann ich SSL-Zertifikat arbeiten auf dem server Ein, so dass es funktioniert durch den Zugriff auf:

https://DOMAIN_NAME_OF_SERVER_A

Das problem ist, ich eingeschlossen, die "apps" im iframe, indem Sie auf "http" wie oben, also mein browser(Chrome) zu verweigern, um es zu öffnen und Fehler melden:


Mixed Content: The page at 'https://DOMAIN_NAME_OF_SERVER_A/xxx' was loaded over HTTPS, but requested an insecure resource 'http://IP_ADDR_OF_SERVER_B:PORT/xxx'. This request has been blocked; the content must be served over HTTPS.


So, wie soll ich umgehen mit einem solchen Problem?
Ich bin ein full-stack grüne hand, würde ich schätzen es sehr, wenn Sie teilen können, einige Kenntnisse, wie man eine gesunde https-website, während die Lösung solcher problem in der richtigen Weise.

---

Ergänzende Erklärung

Ok, ich denke, dass ich nur warf die Umrisse der Frage, hier geht es mehr details.

Ich sehe, es ist intakt und gerade nach vorne, um die iframe-Anfragen bedient werden, die mit https, dann wird es nicht verwirren Sie mich nicht mehr.

Aber das Problem ist, da alle "apps" werden dynamisch erzeugt/entfernt, es scheint, ich werde vorbereiten müssen viele Zertifikate für jeden einzelnen von Ihnen.

Wird selbst signiertes Zertifikat zu arbeiten, ohne blockiert zu werden oder sich beschwert werden, die vom browser? Oder muss ich eine Möglichkeit haben, dienen alle "apps" mit einem SSL-Zertifikat?

---

Software-Umgebung

Server Ein: Running node.js website hören auf port 5000 und serviert mit Nginx proxy_pass.

server {
    listen 80;
    server_name DOMAIN_NAME_OF_SERVER_A;

    location /{
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_pass     http://127.0.0.1:5000;
    }
}
server {
    listen 443;
    server_name DOMAIN_NAME_OF_SERVER_A;

    ssl on;
    ssl_certificate /etc/nginx/ssl/DOMAIN_NAME_OF_SERVER_A.cer;
    ssl_certificate_key /etc/nginx/ssl/DOMAIN_NAME_OF_SERVER_A.key;
    ssl_session_timeout 5m;
    location /{
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;
        proxy_pass     http://127.0.0.1:5000;
    }
}

Server B: Running node.js apps hören von unterschiedlichen random-big-port-Nummern wie 50055, dynamisch zugewiesen, wenn "apps" erstellt. (In der Tat diese Anwendungen laufen, in docker-Containern während ich denke, es spielt keine Rolle) ausführen Können, Nginx, wenn nötig.

Server Ein und Server B sprechen mit einander in den öffentlichen Verkehr.

---

Lösung

So wie all die Antworten, besonders die von @eawenden, ich brauche einen reverse proxy, um meine Absicht zu erreichen.

Zusätzlich habe ich noch ein paar weitere Sachen:
1. Domain-Namen zuordnen zu Server B für die Verwendung einer letsencrypt cert.
2. Proxy-vordefinierte url zu bestimmten port.

Daher richte ich einen reverse-proxy-server mit nginx auf Server B, proxy alle Anfragen wie:

https://DOMAIN_NAME_OF_SERVER_B/PORT/xxx

zu

https://127.0.0.1:PORT/xxx

Ps: nginx-reverse-proxy-config auf Server B

server {
    listen 443;
    server_name DOMAIN_NAME_OF_SERVER_B;

    ssl on;
    ssl_certificate     /etc/nginx/ssl/DOMAIN_NAME_OF_SERVER_B.cer;
    ssl_certificate_key /etc/nginx/ssl/DOMAIN_NAME_OF_SERVER_B.key;
    ssl_session_timeout 5m;

    rewrite_log off;
    error_log   /var/log/nginx/rewrite.error.log info;

    location ~ ^/(?<port>\d+)/{
        rewrite ^/\d+?(/.*) $1 break;
        proxy_pass http://127.0.0.1:$port;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 86400;
    }
}

So scheint alles zu funktionieren wie erwartet!
Nochmals vielen Dank an alle Beantworter.

InformationsquelleAutor librae | 2017-01-11