I launched a gitlab container like this:
sudo docker run --detach --hostname MY_URL.com --publish 4433:443 --publish 8080:80 --publish 2222:22 --name gitlab --og/gitlab --volume /data/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest
And I have a NGINX configuration like this:
server {
server_name MY_URL.com;
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwardedd_for;
proxy_set_header X-Forwarded_Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/MY_URL.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/MY_URL.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = MY_URL.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name MY_URL.com;
return 404; # managed by Certbot
}
With this configuration, everything works fine, I can type https://MY_URL.com in the address bar of my browser and I can get access to my Gitlab.
The problem is that the link to clone in the repositories is "HTTP" and not "HTTPS". Moreover, it seems that there is a configuration somewhere telling my CI jobs to use "HTTP://MY_URL.com" (and it doesn't work because I get an HTTP basic auth error, which I wouldn't get if I used https I think). I read the documentation and I thought I just had to modify the external_url parameter:
sudo vi /data/gitlab/config/gitlab.rb
Adding external_url 'https://MY_URL.com'
sudo docker exec -it gitlab gitlab-ctl reconfigure
But after doing that I always have a "bad redirection" if I write "http://MY_URL.com" or "https://MY_URL.com". In the nginx logs, I don't have any error but only 301 in the access.log.
What am I doing wrong here?
Thanks a lot in advance...
Because you are providing an external NGINX configuration that also terminates SSL, you have to apply a configuration to your GitLab instance for external proxy/load-balancer SSL termination.
Normally, when you don't provide external_url, the system host name is used and HTTPS is disabled. If you provide an external_url with an https:// scheme, this will activate HTTPS, which is not what you want since you are using an external server (NGINX) for SSL/TLS termination.
external_url "https://myhost.com"
nginx['listen_port'] = 80
nginx['listen_https'] = false
This should be all you need to get GitLab to display the correct hostname in the UI without any other behavior changes.
You'll probably also want to change the proxy headers since you already have a proxy server in front of GitLab. You'll want to configure trusted proxies as well as the real-ip header to make sure GitLab correctly logs the IP address of your users (instead of the IP of your proxy).
Related
I launch gitlab with this command:
sudo docker run --detach --hostname example.com --publish 4433:443 --publish 8080:80 --publish 2222:22 --name gitlab --restart always --volume /data/gitlab/config:/etc/gitlab --volume /data/gitlab/logs:/var/log/gitlab --volume /data/gitlab/data:/var/opt/gitlab gitlab/gitlab-ce:latest
example.com being another URL, as you may have guessed.
I have an nginx server with this config:
server {
server_name example.com;
client_max_body_size 50m;
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote-addr;
}
listen 443 ssl;
ssl_certificate [MY PATH TO THE .pem FILE];
ssl_certificate_key [OTHER PATH];
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}
server {
if ($host = example.com) {
return 301 https://$host$request_uri;
}
}
When I use HTTPS to clone and push repos, I have to enter my login/password twice, and when I use ssh (for example git clone git#example.com:myuser/myproject.git), it asks me for a password.
I triple checked, my ssh key configuration is correct.
I left the gitlab.rb config by default, except for this line:
external_url 'https://example.com'
What happens here?
For this particular key, I don't use a passphrase
That means SSH fails to connect to example.com as git, and falls back to the Identity authentication: git's password (which you are not supposed to have).
Using a port syntax HOST_PORT:CONTAINER_PORT, you are supposed to launched your GitLab Docker container with a host port (for instance 2222) mapped to GitLab internal SSH daemon (port 22)
sudo docker run [...] -port 2222:22
Then check it is working with:
ssh -T git#example.com -p 2222
Welcome to GitLab, #you!
With a ~/.ssh/config file, it is easier:
Host gl
hostname example.com
port 2222
User git
IdentityFile ~/.ssh/yourGitLabkey
Then:
ssh -T gh
Welcome to GitLab, #you!
See as examples this thread, or this thread, based on the official documentation "Install GitLab using Docker Compose", mentioned by issue 1767.
I installed gitlab according to the official documentation.
sudo docker run --detach \
--hostname git.stupidpz.com \
--publish 8443:443 --publish 880:80 --publish 822:22 \
--name gitlab \
--restart always \
--volume $GITLAB_HOME/config:/etc/gitlab \
--volume $GITLAB_HOME/logs:/var/log/gitlab \
--volume $GITLAB_HOME/data:/var/opt/gitlab \
--shm-size 256m \
gitlab/gitlab-ee:latest
Now I want to use Nginx(installed By Myself) to reverse proxy gitlab instead of the nginx that comes with the gitlab container.
According to official documentation I added some code in gitlab.rb
# Define the external url
external_url 'http://git.stupidpz.com'
# Disable the built-in nginx
nginx['enable'] = false
# Disable the built-in puma
puma['enable'] = false
# Set the internal API URL
gitlab_rails['internal_api_url'] = 'http://git.stupidpz.com'
# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['nginx']
Then gitlab cannot be accessed, I found some error logs in this file /var/log/gitblab/gitlab_workhorse/current
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:21Z","uri":""}
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:31Z","uri":""}
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:41Z","uri":""}
{"correlation_id":"","duration_ms":0,"error":"badgateway: failed to receive response: dial tcp 127.0.0.1:8080: connect: connection refused","level":"error","method":"GET","msg":"","time":"2023-01-25T20:57:51Z","uri":""}
Did nothing else except for adding some code in gitlab.rb.
I wonder where this dial tcp 127.0.0.1:8080 comes from?
I hope you can help me, or give me a correct demo.Many thanks.This problem has been bothering me for two days
Now i figure out why i could not make it works,I mixed up Using an existing Passenger/NGINX installation and Using a non-bundled web-server
If you just need to use your own nginx to proxy gitlab(both of them was installed on docker)
you just need to add two lines to gitlab.rb.
# Disable the built-in nginx
nginx['enable'] = false
# Define the web server process user (ubuntu/nginx)
web_server['external_users'] = ['nginx']
and here is nginx's conf
upstream gitlab-workhorse {
server unix://var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}
server {
listen *:80;
server_name git.example.com;
server_tokens off;
root /opt/gitlab/embedded/service/gitlab-rails/public;
client_max_body_size 250m;
access_log /var/log/gitlab/nginx/gitlab_access.log;
error_log /var/log/gitlab/nginx/gitlab_error.log;
# Ensure Passenger uses the bundled Ruby version
passenger_ruby /opt/gitlab/embedded/bin/ruby;
# Correct the $PATH variable to included packaged executables
passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";
# Make sure Passenger runs as the correct user and group to
# prevent permission issues
passenger_user git;
passenger_group git;
# Enable Passenger & keep at least one instance running at all times
passenger_enabled on;
passenger_min_instances 1;
location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
location ~ ^/api/v3/projects/.*/repository/archive {
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# Build artifacts should be submitted to this location
location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
client_max_body_size 0;
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# Build artifacts should be submitted to this location
location ~ /ci/api/v1/builds/[0-9]+/artifacts {
client_max_body_size 0;
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# Build artifacts should be submitted to this location
location ~ /api/v4/jobs/[0-9]+/artifacts {
client_max_body_size 0;
# 'Error' 418 is a hack to re-use the #gitlab-workhorse block
error_page 418 = #gitlab-workhorse;
return 418;
}
# For protocol upgrades from HTTP/1.0 to HTTP/1.1 we need to provide Host header if its missing
if ($http_host = "") {
# use one of values defined in server_name
set $http_host_with_default "git.example.com";
}
if ($http_host != "") {
set $http_host_with_default $http_host;
}
location #gitlab-workhorse {
## https://github.com/gitlabhq/gitlabhq/issues/694
## Some requests take more than 30 seconds.
proxy_read_timeout 3600;
proxy_connect_timeout 300;
proxy_redirect off;
# Do not buffer Git HTTP responses
proxy_buffering off;
proxy_set_header Host $http_host_with_default;
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 $scheme;
proxy_pass http://gitlab-workhorse;
## The following settings only work with NGINX 1.7.11 or newer
#
## Pass chunked request bodies to gitlab-workhorse as-is
# proxy_request_buffering off;
# proxy_http_version 1.1;
}
## Enable gzip compression as per rails guide:
## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
## WARNING: If you are using relative urls remove the block below
## See config/application.rb under "Relative url support" for the list of
## other files that need to be changed for relative url support
location ~ ^/(assets)/ {
root /opt/gitlab/embedded/service/gitlab-rails/public;
gzip_static on; # to serve pre-gzipped version
expires max;
add_header Cache-Control public;
}
## To access Grafana
location /-/grafana/ {
proxy_pass http://localhost:3000/;
}
error_page 502 /502.html;
}
last but not least,you need to add another bash to your nginx's container,
-v /var/opt/gitlab:/var/opt/gitlab
This will let your nginx container connect to gitlab container.Otherwise you will get "cannot find var/opt/gitlab/gitlab-workhorse/sockets/socket".
It looks like you are installing a GitLab instance as a custom git server on a remote host. There are 3 pieces of this that must work.
DNS setup, remote host's ports and firewall setup.
Working installation of GitLab on the remote host.
Valid SSL certificates, and a correct nginx config for HTTPS.
The first step really depends on your virtual machine and container's setup, but essentially, make sure it (the VM or container) has a public port that responds to requests.
These variables must be set in the remote host's environment as such
--volume $GITLAB_HOME/config:/etc/gitlab
--volume $GITLAB_HOME/logs:/var/log/gitlab
--volume $GITLAB_HOME/data:/var/opt/gitlab \
The above URL covers all the GitLab install steps once you have signed in and verified that it was installed correctly and that it runs as expected on that remote host.
Only then, install and configure nginx. Since GitLab likely will transfer credentials and other secure data, you will need to setup https on nginx.
An example of an Nginx configuration can be found here. There is also a tool by Mozilla that makes building a custom nginx config easier, found here.
The error you show has this URL "127.0.0.1:8080". It is likely you have supplied this URL to the gitlab.rb config somewhere, and that might be a mistake. I cannot be sure without the whole config file however.
Also, it is likely the GitLab image will need to run its own nginx instance, so that the said container when launched may do its job and act as a git server. To reverse proxy this GitLab instance, you may need to install nginx onto your host machine and point it to GitLab Image's nginx.
You may be able to do away with the second nginx instance by appending a new server {} block into the Gitlab Image's nginx config. I would not recommend this.
I have a Docker container on port 8081 running on Centos7, and a reverse proxy with Nginx.
My domain have a LetsEncrypt SSl installed and it works good when i access "https://my.example.com", it redirects me to my 8081 Docker.
But i when i access "http://my.example.com:8081", i still can reach my Docker application...i don't want to enable this...don't want to enable any http access.
I want to reach 8081 only through Nginx reverse proxy (that forces me to https)...i think it may be some configuration on my iptables, but i don't have experience with it.
Can someone help me?
Thanks!
This is my conf.d file in Nginx
server{
server_name my.example.com;
location / {
proxy_pass http://localhost:8081;}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/my.example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/my.example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server{
if ($host = my.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name my.example.com;
return 404; # managed by Certbot
}
iptables does not understand the difference between HTTP or HTTPS, it understands only ip; ports and mac levels, if you try to block port 8081 with iptables even your https connection will be dropped or rejected depending on your choice.
If your docker container is accessible from the outside without passing through the reverse proxy, it is a container configuration issue, or if your nginx reverse proxy lets through http packets, then it is an nginx configuration issue, I think we need more details from your side.
I have resolved this issue using the firewall application from my hosting provider(Vultr).
There, i left 8081 only for local access, so now it's not possible to access this without passing through Nginx reverse proxy!
I set up the Letsencrypt certificate directly to an AWS EC2 Ubuntu instance running Nginx and a docker server using port 9998. The domain is set up on Route 53. Http is redirected to https.
So https://example.com is working fine but https://example.com:9998 gets ERR_SSL_PROTOCOL_ERROR. If I use the IP address like http://10.10.10.10:9997 is working and checked the server using port 9998 okay.
The snapshot of the server on docker is:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
999111000 img-server "/bin/sh -c 'java -j…" 21 hours ago Up 21 hours 0.0.0.0:9998->9998/tcp hellowworld
It seems something is missing between Nginx and the server using port 9998. How can I fix it?
Where have you configured the ssl certificate ? Only Nginx?
The reason why you cannot visit https://example.com:9998 using ssl protocal is that that port provides http service rather than https.
I suggest not to publish 9998 of hellowworld and proxy all the traffic with nginx (if Nginx is also started with docker and in the same network).
Configure https in Nginx and the origin sever provides http.
This is a sample configuration https://github.com/newnius/scripts/blob/master/nginx/config/conf.d/https.conf
server {
listen 80;
server_name example.com;
return 301 https://example.com$request_uri;
}
server {
listen 443;
server_name example.com;
access_log logs/example.com/access.log main;
error_log /var/log/nginx/debug.log debug;
ssl on;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://apache:80;
proxy_set_header Host $host;
proxy_set_header CLIENT-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ /.well-known {
allow all;
proxy_pass http://apache:80;
}
# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store(Mac).
location ~ /\. {
deny all;
}
}
I'm receiving the error Authentication required after I login in the Wildfly 13 Management Console.
If I type a user or password wrong, it asks again, but if I type correctly it shows the page with the error message (so I assume the user and password are correct, but something else after that gives the error).
I'm using docker to run a nginx container and a wildfly container.
The nginx listens externally on port 9991 and proxy pass the request to the wildfly container, but it shows the error described before.
It just happens with the Wildfly Console, every other request proxied, even request proxied to a websocket or to Wildfly on port 8080, are done successfully.
The Wildfly container listens externally on port 9990 and I can access the console successfully in this port. If on docker I map the port "9992:9990" I still can access the console successfully through port 9992.
So, it seems that this is not related to docker, but to the Wildfly Console itself. Probably some kind of authentication that is not happening successfully when using a reverse proxy in the middle.
I have a demo docker project on https://github.com/lucasbasquerotto/pod/tree/0.0.6, and you can download the tag 0.0.6 that has everything setup to work with Wildfly 13 and nginx, and to simulate this error.
git clone -b 0.0.6 --single-branch --depth 1 https://github.com/lucasbasquerotto/pod.git
cd pod
docker-compose up -d
Then, if you access the container directly in http://localhost:9990 with user monitor and password Monitor#70365 everything works.
But if you access http://localhost:9991 with the same credentials, through the nginx reverse proxy, you receive the error.
My nginx.conf file:
upstream docker-wildfly {
server wildfly:9990;
}
location / {
proxy_pass http://docker-wildfly;
proxy_redirect off;
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-Host $server_name;
}
I've also tried with:
proxy_set_header X-Forwarded-Proto $scheme;
And also with the Authorization header (just the 2nd line and also with both):
proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;
And also defining the host header with the port (instead of just $host):
proxy_set_header Host $server_addr:$server_port;
I've tried the above configurations isolated and combined together. All to no avail.
Any sugestions?
Has anyone successfully accessed the Wildfly Console through a reverse proxy?
Update (2018-09-22)
It seems Wildfly uses a digest authentication (instead of basic).
I see the header in the console like the following:
Authorization: Digest username="monitor", realm="ManagementRealm", nonce="AAAAAQAAAStPzpEGR3LxjJcd+HqIX2eJ+W8JuzRHejXPcGH++43AGWSVYTA=", uri="/console/index.html", algorithm=MD5, response="8d5b2b26adce452555d13598e77c0f63", opaque="00000000000000000000000000000000", qop=auth, nc=00000005, cnonce="fe0e31dd57f83948"
I don't see much documentation about using nginx to proxy pass requests with digest headers (but I think it should be transparent).
One question I saw here in SO is https://serverfault.com/questions/750213/http-digest-authentication-on-proxied-server, but there is no answer so far.
I saw that there is the nginx non-official module https://www.nginx.com/resources/wiki/modules/auth_digest/, but in the github repository (https://github.com/atomx/nginx-http-auth-digest) it says:
The ngx_http_auth_digest module supplements Nginx's built-in Basic
Authentication module by providing support for RFC 2617 Digest
Authentication. The module is currently functional but has only been
tested and reviewed by its author. And given that this is security
code, one set of eyes is almost certainly insufficient to guarantee
that it's 100% correct. Until a few bug reports come in and some of
the ‘unknown unknowns’ in the code are flushed out, consider this
module an ‘alpha’ and treat it with the appropriate amount of
skepticism.
Also it doesn't seem to me allright to hardcode the user and pass in a file to be used by nginx (the authentication should be transparent to the reverse proxy in this case).
In any case, I tried it and it correctly asks me to authenticate, even if the final destination does not have a digest authentication, like when trying to connect to the wildfly site (not console), it asks when trying to connect to nginx (before proxying the request), then it forwards successfully to the destination, except in the case of wildfly console, it keeps asking me to authenticate forever.
So I think this is not the solution. The problem seems to be in what the nginx is passing to the Wildfly Console.
I had the same problem with the HAL management console v3.3 and 3.2
I could not get ngnix HTTPS working due to authentication errors, even though the page prompted http basic auth user and pass
This was tested in standalone mode on the same server
My setup was :
outside (https) -> nginx -> http://halServer:9990/
This resulted in working https but with HAL authentication errors (seen in the browsers console) the webpage was blank.
At first access the webpage would ask http basic auth credentials normally, but then almost all https requests would return an authentication error
I managed to make it work correctly by first enabling the HAL console https with a self signed certificate and then configuring nginx to proxy pass to the HAL HTTPS listener
Working setup is :
outside (https) -> nginx (https) -> https://halServer:9993/
Here is the ngnix configuration
server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name halconsole.mywebsite.com;
# SSL
ssl_certificate /keys/hal_fullchain.pem;
ssl_certificate_key /keys/hal_privkey.pem;
ssl_trusted_certificate /keys/hal_chain.pem;
# security
include nginxconfig.io/security.conf;
# logging
access_log /var/log/nginx/halconsole.mywebsite.com.access.log;
error_log /var/log/nginx/halconsole.mywebsite.com.error.log warn;
# reverse proxy
location / {
# or use static ip, or nginx upstream
proxy_pass https://halServer:9993;
include nginxconfig.io/proxy.conf;
}
# additional config
include nginxconfig.io/general.conf;
include nginxconfig.io/letsencrypt.conf;
}
# subdomains redirect
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name *.halconsole.mywebsite.com;
# SSL
ssl_certificate /keys/hal_fullchain.pem;
ssl_certificate_key /keys/hal_privkey.pem;
ssl_trusted_certificate /keys/hal_chain.pem;
return 301 https://halconsole.mywebsite.com$request_uri;
}
proxy.conf
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
# Proxy headers
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Forwarded $proxy_add_forwarded;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-By $server_addr;
# Proxy timeouts
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
The easiest way to enable https console is by using the console itself
generate a java JKS keystore using either the command line keytool or a GUI program
I like GUIs, so I used Key Store Explorer https://github.com/kaikramer/keystore-explorer
copy keystore file on the halServer server where it has read access (no need to keep it secret) i placed mine inside wildfly data dir in a "keystore" directory.
# your file paths might differ, don't copy paste
cp /home/someUser/sftp_uploads/managementKS /opt/wildfly/standalone/data/keystore/managementKS
set permissions
# your file paths might differ, don't copy paste
chown --recursive -H wildfly:wildfly /opt/wildfly/standalone/data/keystore
(use vpn) login to cleartext console http://halServer:9990/
add keystore : navigate :
configuration -> subsystems -> security (elytron) -> other settings (click view button)
stores -> keystore -> add
...
Name = managementKS
Type = JKS
Path = keystore/managementKS
Relative to = jboss.server.data.dir
Credential Reference Clear Text = keystore-password click Add
result in standalone.xml
<key-store name="managementKS">
<credential-reference clear-text="keystore-password"/>
<implementation type="JKS"/>
<file path="keystore/managementKS" relative-to="jboss.server.data.dir"/>
</key-store>
add key manager : navigate :
ssl -> key manager -> add
...
Name = managementKM
Credential Reference Clear Text = keystore-password
Key Store = managementKS
result in standalone.xml
<key-manager name="managementKM" key-store="managementKS">
<credential-reference clear-text="keystore-password"/>
</key-manager>
add ssl context : navigate :
ssl -> server ssl context -> add
...
Name = managementSSC
Key Manager = managementKM
...
Edit added : Protocols = TLSv1.2
save
result in standalone.xml
<server-ssl-contexts>
<server-ssl-context name="managementSSC" protocols="TLSv1.2" key-manager="managementKM"/>
</server-ssl-contexts>
go back
runtime -> server (click view button)
http management interface (edit)
set secure socket binding = management-https
set ssl context = managementSSC
save
restart wildfly
systemctl restart wildfly