It's not possible to import bought certificates with key about docker-archiva HOT 3 CLOSED

@jryberg I'm 90% sure you're looking to configure your archiva container to support serving content over HTTPS. Providing I'm right, there's only one way to do that without a proxy and it's briefly covered in the second example in the readme.

You just need to setup a java keystore with the key pairs you want archiva to use, then use the KEYSTORE_* environment variables to get the image to use it.

If you're new to java keystores, there are ton of good "quick start" style guides out there. Digital Ocean has a pretty good one. And, if nothing else, you can checkout our parameterized commands for setting up a JKS with a self-signed certificate in the run.bash.

Once you have java keystore setup, see the second example for how to use it to serve content over HTTPS.

from docker-archiva.

Hi,

Yes, I want https without self signed certificates but for that you need to be able to import intermediate certificate, the actual certificate and the key for the certificate.

It's not really possible to do this without creating a custom keystore and import it.

I managed to use nginx as a reverse proxy for https with my certificates and that works perfectly fine.

The only tweak I had to do was disable csr protection until I figure out what wrong I'm doing with rest.baseUrl (https://archiva.apache.org/docs/2.2.3/adminguide/customising-security.html)

If anyone are interested this is how I did it using docker-compose

docker-compose.yml

version: "3"
services:
  reverseproxy:
    image: nginx
    restart: unless-stopped
    ports:
      - "8443:8443"
    volumes:
      - /data/archiva-compose/proxy_ssl.conf:/etc/nginx/conf.d/proxy_ssl.conf:ro
      - /data/archiva-compose/ssl.crt:/etc/nginx/ssl.crt:ro
      - /data/archiva-compose/ssl.key:/etc/nginx/ssl.key:ro

  archiva:
    image: xetusoss/archiva
    restart: unless-stopped
    depends_on:
      - "reverseproxy"
    ports:
      # It's not nessary to export this port, but I wanted another service on the same host to be able to access Archiva unencrypted.
      - "127.0.0.1:8080:8080"
    volumes:
      - /data/archiva:/archiva-data

proxy_ssl.conf

server {
  listen 8443;
  server_name <replace with FQDN>;

  ssl_certificate           /etc/nginx/ssl.crt;
  ssl_certificate_key       /etc/nginx/ssl.key;

  ssl on;
  ssl_session_cache  builtin:1000  shared:SSL:10m;
  ssl_protocols TLSv1.2;
  ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
  ssl_prefer_server_ciphers on;


  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-Port "8443";
    proxy_pass       http://archiva:8080;
    proxy_redirect   off;
  }
}

from docker-archiva.

@jryberg

I think there's just a misunderstanding here.

... for that you need to be able to import intermediate certificate, the actual certificate and the key for the certificate.

It's not really possible to do this without creating a custom keystore and import it...

That's right, but that's not a problem! That's how it's supposed to work. Some servers want their SSL keys as PEM files, some as P12, some in JKS's (or maybe some combination). Jetty, which is what Archiva uses in this image, is a standard servlet container and supports a standard a JKS.

What you're talking about is a quite common thing to do, which is why it's our second example.

It seems like a lot of effort to setup, configure, and test an nginx proxy for the sole reason of avoiding creating a JKS. Is there some reason you can't use a java keystore? A proxy is a fine solution, but you usually do that when you have some other motivation (e.g. network path restrictions, request logging, a KMS, etc) and I haven't heard any mention of things like that.

from docker-archiva.