Jenkins usando JNLP por trás do proxy reverso SSL nginx

Question

Eu gostaria de usar o JNLP para conectar escravos jenkins ao mestre jenkins. O mestre está executando um proxy SSL nginx configurado de acordo com a documentação oficial . Além dessa documentação, me deparo com problemas relacionados a certificados.

Atualmente, posso fazer com que o escravo sem cabeçalho JNLP domine a conexão para funcionar apenas com conexão HTTP não segura, mas não com HTTPS (embora o meu painel do jenkins seja em geral). Eu uso um certificado auto-assinado assinado por meu próprio certificado de CA personalizado (x509 com base em openssl).

Então, como eu digo ao binário java do meu escravo para confiar no meu certificado CA SSL? Eu tentei isso.

# add CA certificate to key store
$ keytool -import -file /usr/local/share/ca-certificates/my_ca.crt -alias my_ca -storepass mypassword

# try to reference keystore to JNLP headless call
$ java -Djavax.net.ssl.keyStorePassword=mypassword -Djavax.net.ssl.keyStore=/home/myuser/.keystore -jar slave.jar -jnlpUrl https://proxied-jenkins.example.com/computer/testslave/slave-agent.jnlp

Na verdade, o JAVA parece não procurar o certificado dentro do keystore fornecido. Qual é o meu erro aqui?

EDITAR

Similar / mesmo problema ocorre quando se usa jenkins cli. De acordo com isso , agora eu suponho, não tem nada a ver com a confiança do meu certificado porque não consigo ver a javax.net.ssl.SSLHandshakeException

Acabei de receber uma reinicialização de conexão

Failing to obtain https://proxied-jenkins.example.com/computer/testslave/slave-agent.jnlp
java.net.SocketException: Connection reset
    at java.net.SocketInputStream.read(SocketInputStream.java:196)
    at java.net.SocketInputStream.read(SocketInputStream.java:122)
    at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
    at sun.security.ssl.InputRecord.read(InputRecord.java:480)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
    at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:269)
    at hudson.remoting.Launcher.run(Launcher.java:219)
    at hudson.remoting.Launcher.main(Launcher.java:192)

.. então eu assumo um problema de configuração com o meu proxy. Tomei a configuração de configuração de proxy reverso e adicionei a seguinte configuração para forçar o SSL:

upstream jenkins-upstream {
  server unproxied-jenkins.example.com:8080 fail_timeout=0;
}

server {
  listen 80;
  server_name proxied-jenkins.example.com;
  return 301 https://$host$request_uri;
}
server {
  listen 443;
  server_name proxied-jenkins.example.com;

  #this is the jenkins web root directory (mentioned in the /etc/default/jenkins file)
  root            /var/run/jenkins/war/;

  ssl on;
  ssl_certificate /etc/nginx/conf.d/proxied-jenkins.example.com.crt;
  ssl_certificate_key /etc/nginx/conf.d/proxied-jenkins.example.com.key;
  ssl_protocols TLSv1.2;
  ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH;

  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;

  [...] # continuing according to jenkins documentation
  location @jenkins {
      proxy_pass                  http://jenkins-upstream
      [....]
  }
  [....]
}

Novamente, ao alterar para HTTP não seguro, o JNLP e o jenkins-cli funcionam conforme o esperado. Então, qual é o erro?
Talvez eu precise passar informações adicionais sobre o cabeçalho? Talvez eu precise de configuração SSL adicional nas minhas configurações de proxy?

    

Answer 1

(Expandido com base no feedback sobre comentários)

Esse servidor está configurado para exigir a versão de protocolo TLSv1.2 (somente) e ciphersuites usando pelo menos um AES-GCM ou AES de 256 bits, com troca de chave DHE ou ECDHE (para o qual o OpenSSL e o nginx usam variante grafias EDH e EECDH em alguns casos incluindo este).

Cliente JSSE no Oracle ou OpenJDK O JDK7 não oferece TLSv1.2 ou 1.1 por padrão (não sabe para a IBM, que possui seus próprios provedores de criptografia), mas eles são implementados e pode ser ativado ; para (Https)URLConnection , isso pode ser feito com a propriedade do sistema https.protocols . (Ou sobrepondo sua fábrica de soquete, mas a propriedade do sistema é geralmente mais fácil.) Mas o JDK7 não implementa as versões do GCM e Oracle (mas NÃO as do OpenJDK) proíbe a criptografia simétrica de 256 bits você instala os "Arquivos de Política de Jurisdição do JCE Unlimited Strength " no site da Oracle; consulte o link e possivelmente link

Em contraste, o JDK8 (Oracle e OpenJDK) oferece TLSv1.2 e 1.1 por padrão e implementa o GCM, para que ele possa se conectar sem a política Unlimited Strength.

Tanto o 7 como o 8 suportam o intercâmbio de chaves DHE e ECDHE. Mas para qualquer outra pessoa em situação semelhante com o JDK6: o ECDHE não funciona a menos que você adicione um provedor de terceiros para primitivos ECC como bcprov de link

    

Answer 2

Para googlers que acessam essa página com base no título e não no conteúdo dessa pergunta e desejam que os escravos do JNLP se conectem a um Jenkins com proxy reverso em execução em um servidor separado, em vez de no servidor de proxy reverso, veja minha resposta para Jenkins: Como configurar o Jenkins por trás do proxy reverso Nginx para que os escravos JNLP se conectem .