Hello I configured Gitlab server on a VM OL7. I can easily call the http page. but when I use my self-signed ssl certificate generated using the method offered here, I can't call my page and I get a timeout as error. My configuration is simple and I have already tried different variants someone could tell me how I can configure this one. note that I don't want to use let's encrypt for this.
this is an example of my gitlab.rb
external_url 'http://gitlab.icw19.lab'
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.icw19.lab.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.icw19.lab.key"
Your external_url value should include https:// to indicate that you wish to use SSL on port 443. Then GitLab will listen on 443 and will configure Nginx to use your SSL certificates.
external_url 'https://gitlab.icw19.lab'
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.icw19.lab.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.icw19.lab.key"
Related
I have been trying to access my local gitlab server with https by creating root and websited certificates.
I have used the below link and in place of Node js application,
https://www.section.io/engineering-education/how-to-get-ssl-https-for-localhost/
I have changed my configuration in gitlab.rb file with
external_url "https://gitlab.mydomain.com"
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/ssl/mydomain/gitlab.crt"
nginx['ssl_certificate_key'] = "/etc/ssl/mydomain/gitlab.key"
and reconfigured the gitlab inside my docker container.
And I imported my root pem(CA.pem) into the browser. But it still showing the connection not secure.
Can you please help me to get my gitlab with https connection.
Doesn't seem to find my certificate. When I visit site with https advise if certificate is out of date and points to when the domain was first set up doesn't seem to use or find the new certificates.
Have created new lets encrypt certs in plesk (CENT OS) and even as advised copied and moved said certs to a folder in /var/lib/couchdb/certs/
gave teh folder and certs CouchDB ownership and certs also set to 600 and edited .ini as follows and restarted CouchDB but just doesn't seem to work.
[daemons]
; enable SSL support by uncommenting the following line and supply the PEM's below.
; the default ssl port CouchDB listens on is 6984
httpsd = {chttpd, start_link, [https]}
[ssl]
cert_file = /var/lib/couchdb/certs/fullchain.pem
key_file = /var/lib/couchdb/certs/privkey.pem
I'm running Samba 4.3.11-Ubuntu on Ubuntu 16.04, and I'm unable to get LDAPS (port 636) to work at all.
Samba is running as an Active Directory Domain Controller, and other AD DC fncitonality seems to be fine.
This used to work, but now there's nothing listening on that port. I'm not sure what I did to break it, but it stopped working after I updated my server with a trusted certificate.
Here's what I have for /etc/samba/smb.conf:
# Global parameters
[global]
workgroup = AD
realm = AD.<redacted>.COM
netbios name = SAMBADC
server role = active directory domain controller
dns forwarder = 8.8.8.8
idmap_ldb:use rfc2307 = yes
tls enabled = yes
tls keyfile = tls/ad.<redacted>.com.key
tls certfile = tls/c7535fc6c5e8e557.crt
tls cafile = tls/gd_bundle-g2-g1.crt
ldap server require strong auth = allow_sasl_over_tls
[netlogon]
path = /var/lib/samba/sysvol/ad.<redacted>.com/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
The error I'm getting is:
nitsadmin#sambadc:/etc/samba$ telnet localhost 636
Trying 127.0.0.1...
Trying ::1...
telnet: Unable to connect to remote host: Cannot assign requested address
Anyone have any idea why this might not work? Any idea what Cannot assign requested address means?
Could you please provide a log file which is specified in your smb.conf parameter log file = while you start the samba service?
There could be something wrong with your certificates.
One thing you could try is to switch to autogenerated self-signed certificate and see if it solves the issue. If it does - you have to fix your certificates.
To do this, remove all certificates from tls folder and reconfigure smb.conf:
tls enabled = yes
tls keyfile = tls/key.pem
tls certfile = tls/cert.pem
tls cafile = tls/ca.pem
Then restart samba service and see if it helps.
I try to activate ssl of emqttd server. For this, I added following lines to emq.conf under the etc folder.
mqtt.listener.ssl.tls_versions = tlsv1.2,tlsv1.1,tlsv1
mqtt.listener.ssl.handshake_timeout = 15s
mqtt.listener.ssl.keyfile = etc/certs/key.pem
mqtt.listener.ssl.certfile = etc/certs/cert.pem
mqtt.listener.ssl.cacertfile = etc/certs/cacert.pem
mqtt.listener.ssl.verify = verify_peer
All other settings is same to default.
However, I can connect my local mqtt server without doing any ssl configuration like ssl version, certificate, etc. by using mqtt-spy broker. I think i didn' t configure ssl properties of emqttd. How can i solve this problem?
Thanks in advance.
You must check which port you are trying on for SSL.
Secondly you need to place your key.pem and cert.pem at the path mentioned.
It will just work fine if client have the certificate to authenticate the server.
I'm running the Omnibus version of Gitlab in docker.
I've edited my gitlab.rb file so as to enable https by prefixing external_url with https://. This seems to work well enough. However, when I also add my port to the URL:
external_url = 'https://www.example.com:12345'
My browser shows me a "connection refused" error. Why is this?
If you want to change the default port where GitLab is running, you have to put this in your gitlab.rb file :
gitlab_rails['gitlab_host'] = 'example.com'
gitlab_rails['gitlab_port'] = 12345
gitlab_rails['gitlab_https'] = true
After you set this parameters, you'll have to run a # gitlab-ctl reconfigure
Also take a look at /opt/gitlab/embedded/service/gitlab-shell/config.yml: you can find here interesting parameters for: the SSL certificates path
http_settings:
#user: someone
#password: somepass
ca_file: /etc/ssl/cert.pem
ca_path: /etc/pki/tls/certs
self_signed_cert: false