Como verificar o apache para disponibilidade de SNI (Server Name Indication)?

3

Eu tenho um servidor centos 7. Eu mudei do apache 2.4.6 para o apache 2.4.25 usando o repositório IUS ( link ). Meu objetivo é oferecer suporte a vários certificados SSL com um único IP.

Eu instalei:

  • Apache / 2.4.25 (CentOS)
  • link
  • openssl-1.0.1e-60.el7_3.1.x86_64

O apache agora está habilitado para SNI?

Ou eu tenho que construí-lo do zero com ./configure --with-ssl = / path / para / your / openssl como na documentação ( link )?

Obrigado pelo seu tempo.

    
por GeorgeKaf 19.05.2017 / 09:16

1 resposta

6

O estoque CentOS httpd & Os pacotes mod_ssl já teriam suportado o SNI. O SNI tem sido suportado pelo openssl desde a versão 0.9.8f e qualquer httpd desde a versão 2.2.12 construída com o openssl 0.9.8f e o mais recente automaticamente suportará o SNI.

Mas para verificar se o seu httpd e mod_ssl suportam o SNI:

Basta testar configurando hosts virtuais SSL / TLS baseados em nome e verificar seu log de erros após a reinicialização (a partir do apache httpd wiki você já está ligado a):

How can you tell if your Apache build supports SNI?

If you configure multiple name-based virtual hosts for an address where SSL is configured, and SNI isn't built into your Apache, then upon Apache startup a message like

"You should not use name-based virtual hosts in conjunction with SSL!!"

     

ocorrerá no log de erros.
  Se o SNI estiver integrado, o log de erros será exibido

     

"[warn] Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)".

Como alternativa, use ldd para confirmar que o mod_ssl está vinculado ao libssl do openssl e confirme a versão:

ldd /usr/lib64/httpd/modules/mod_ssl.so
    linux-vdso.so.1 =>  (0x00007fff323f8000)
    libssl.so.10 => /lib64/libssl.so.10 (0x00007f3d99792000)        <=======
    libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f3d993a8000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3d9918b000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f3d98f87000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f3d98bc6000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f3d98977000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f3d98690000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f3d9848c000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f3d98259000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f3d98043000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f3d99c3d000)
    libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f3d97e34000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f3d97c2f000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f3d97a15000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f3d977ed000)
    libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f3d9758c000)
rpm -qf /lib64/libssl.so.10
openssl-libs-1.0.1e-60.el7_3.1.x86_64
    
por 19.05.2017 / 09:58