Как использовать встроенный Jetty с HTTPS через порт, отличный от 443?

Я обслуживал веб-приложение через HTTPS на порту 443 по умолчанию со встроенным Jetty (давайте назовем этот serverA) в Ubuntu 14.04 (используя самозаверяющий сертификат). Он уже давно работает нормально, но я хочу запустить еще один встроенный веб-сервер Jetty (serverB) на том же компьютере. Я бы хотел, чтобы serverB запускал SSL, используя порт 443 по умолчанию, поэтому мне нужно изменить serverA, чтобы он прослушивал запросы на каком-то другом порту.

Я пробовал serverA с 444 и 8080. Сервер запускается просто отлично, сообщая мне, что он прослушивает запросы на правильном порту. но запросы просто зависают, и журналы сервера ничего мне не говорят. Если я запускаю сервер для прослушивания порта 443, то все работает нормально.

Я не думал, что имеет значение, какой порт я использую, если мой веб-сервер настроен на использование SSL. Есть ли что-то еще, что мне нужно сделать?

Вот мой код запуска:

    // Java 7 bug (feature?) - this disables SNI everywhere...
    // required or else outgoing HTTPS requests will fail
    System.setProperty("jsse.enableSNIExtension", "false");

    PropertyConfigurator.configure("./log4j.properties");
    Server server = new Server();

    WebAppContext webapp = new WebAppContext();
    webapp.setContextPath("/");
    webapp.setWar("war");
    server.setHandler(webapp);

    HttpConfiguration https = new HttpConfiguration();
    https.addCustomizer(new SecureRequestCustomizer());

    SslContextFactory sslContextFactory = new SslContextFactory();
    sslContextFactory.setKeyStorePath("keystore.jks");
    sslContextFactory.setKeyStorePassword("password");
    sslContextFactory.setKeyManagerPassword("password");

    ServerConnector sslConnector = new ServerConnector(server,
            new SslConnectionFactory(sslContextFactory, "http/1.1"),
            new HttpConnectionFactory(https));
    sslConnector.setPort(port);

    server.setConnectors(new Connector[] { sslConnector });

    try {
        LOG.info("Starting server on port " + port);
        server.start();
        server.join();

    } catch (Exception e) {
        LOG.fatal("The web server has crashed", e);
    }

Примечание. Причина, по которой это происходит в StackOverflow, а не в режиме SuperUser или в чем-то еще, заключается в том, что, насколько я понимаю, порт, используемый для HTTPS, не важен. Я предполагаю, что это проблема Jetty.

Изменить:
Извините, забыл упомянуть версию Jetty. Это 9.2.0


person RTF    schedule 02.10.2014    source источник
comment
Пока вы используете выпущенную и стабильную пристань (не M0, M1, RC0 и т. д.), все в порядке. Последняя зрелая/стабильная версия: 9.2.3.v20140905   -  person Joakim Erdfelt    schedule 02.10.2014
comment
Так случилось, что я использую jetty-all-9.2.0.M0.jar — не следует ли?   -  person RTF    schedule 02.10.2014
comment
Это предварительная версия Milestone 0, которая считается нестабильной и предназначена только для тестировщиков.   -  person Joakim Erdfelt    schedule 02.10.2014


Ответы (1)


Попробуйте это, так как вы не сказали причалу, что считается безопасным, он просто использует значения по умолчанию.

HttpConfiguration https = new HttpConfiguration();
https.setSecurePort(port); /* missing this */
https.addCustomizer(new SecureRequestCustomizer());

Это может показаться странным, но на самом деле необходимо, потому что вас можно считать безопасным, даже если соединение пришло небезопасным способом. Например, с прокси-сервера или балансировщика нагрузки с завершением ssl перед пристанью (разнообразие способов просто ошеломляет)

person Joakim Erdfelt    schedule 02.10.2014
comment
sslConnector.setPort(port) все еще требуется? - person RTF; 02.10.2014
comment
Все еще зависает на порту 444 с оператором, включенным в ваше решение. Я попытался удалить sslConnector.setPort(port), но это тоже не работает. - person RTF; 02.10.2014
comment
Ваш код отлично работает здесь (я выбрал порт 12444 только потому, что я не работал как root). Попробуйте порт выше 1024, если он работает, то вы либо сталкиваетесь с проблемами привилегированного порта, либо с проблемами брандмауэра. - person Joakim Erdfelt; 02.10.2014
comment
Га, я знаю, что это такое. Я работаю на экземпляре AWS EC2 с ограничениями входящего IP/порта — спасибо! - person RTF; 02.10.2014