How to Set Up SSL on a Self-Hosted GitLab Server

Use the registry reload when its certificate changed. The first command reloads the bundled NGINX process; the second is relevant only when the registry is enabled and its certificate is affected.

Configure an external reverse proxy or load balancer

A proxy or load balancer can terminate TLS while GitLab receives HTTP on a private backend connection. In this design, the public certificate belongs on the proxy, not in the bundled NGINX certificate directory. GitLab must know that the original request was HTTPS, otherwise it can generate HTTP links, redirect in a loop, or reject requests protected by CSRF checks.

1. Make the Omnibus backend HTTP-only

For a proxy that sends traffic to port 80, set:

external_url "https://gitlab.example.com"
gitlab_rails['nginx']['listen_port'] = 80
gitlab_rails['nginx']['listen_https'] = false

Then apply the change:

sudo gitlab-ctl reconfigure

The HTTPS scheme in external_url remains important because it describes the public URL. The listen settings describe only the connection between the proxy and GitLab.

2. Forward the original request information

Configure the proxy to pass the original host and scheme, the client address, and the public port. At minimum, GitLab's documentation calls out these headers:

• Host — the public GitLab hostname.
• X-Forwarded-Ssl — indicates that the client used HTTPS.
• X-Forwarded-For — preserves the client address chain.
• X-Forwarded-Port — identifies the public listener, normally 443.

Use the proxy's documented syntax to set or overwrite these values rather than blindly trusting values supplied by an untrusted client. Restrict backend access so users cannot bypass the proxy and inject their own forwarded headers.

3. Diagnose redirect loops and 422 errors

A redirect from HTTPS back to HTTPS, or an endless HTTP-to-HTTPS loop, usually means the backend is not receiving the public host or scheme correctly. A “422 Unprocessable Entity” response during sign-in or form submission can indicate that GitLab's CSRF protection sees inconsistent host, port, or scheme headers. Inspect the proxy request headers and GitLab logs, correct the forwarding configuration, and re-run the request from a clean browser session.

4. Decide where HTTP-to-HTTPS redirection belongs

Either the proxy or GitLab can redirect HTTP. Keep the rule in one place to avoid conflicting behavior. If the proxy owns the redirect, it must still allow any ACME HTTP-01 path when automatic certificate issuance or renewal uses that challenge. If the proxy is the sole public endpoint, its certificate renewal and redirect policy become part of the GitLab service's availability plan.

Rank #4

Sale

Vaydeer Wrist Rest for Keyboard and Mouse, Computer Ergonomic Wrist Support Pad, Soft Memory Foam Arm Cushion for Desk, Palm Hand Office Laptop Typing

• 【Softer and More Comfortable】Vaydeer wrist rest has unique diamond pattern, which is the combination of softness and aesthetics. The materials of wrist rest are improved into higher quality memory foam and covered with silky smooth lycra. The computer wrist rest makes you as comfortable and cushiony as like rest your wrists on clouds.
• 【Ergonomic Wrist Saver】The wrist rests for keyboard and mouse comes with a 17.32×3.15×0.83 inch keyboard wrist pad and a 5.94×3.15×0.83 inch mouse wrist support. Based on ergonomic design, the unique concave shape is the perfect fit for your wrist joints. The wrist rest pad fits most computer keyboards and laptops, improve hand and wrist posture, release your wrist and arm stress.
• 【Non-Slip Rubber Bottom】Featuring an anti-skid silicone base on the bottom, this wrist keyboard support stays firmly in place on your desk, preventing the padding from sliding around, ensuring stable and consistent wrist support during extended computer sessions.
• 【Better Experience & Pain Relief】Our keyboard arm rest is beneficial to alleviate the soreness caused by direct contact and friction between your arm and a hard desk surface, reducing the risk of wrist fatigue or carpal tunnel. The soft texture of memory foam can evenly distribute the pressure around your wrists and provide good support with just enough give.
• 【Helpful in Multiple Scenarios】Whether you're working, studying, writing, typing, gaming, this keyboard and mouse rest combo is an essential accessory to add comfort and support to your hands and wrists. It’s also a great gift for men, women, family, friend, coworker, gamer, teacher, etc.

$15.99

Buy on Amazon

Verify the live certificate and chain

Do not declare the setup complete merely because a browser displays a padlock. Test from a client that resolves the same hostname users will use and inspect the certificate chain presented on port 443.

Inspect the remote endpoint with GitLab's OpenSSL binary

echo | /opt/gitlab/embedded/bin/openssl s_client -connect gitlab.example.com:443

Review the output for the subject and subject-alternative names, validity dates, issuer, and chain. A successful verification normally ends with Verify return code: 0 (ok). If the command shows an incomplete chain, a hostname mismatch, or an expired certificate, fix the certificate or proxy configuration before testing application logins and Git operations.

Inspect a local certificate file

/opt/gitlab/embedded/bin/openssl x509 -in /path/to/certificate.crt -text -noout

Check that the hostname appears in the certificate's subject-alternative-name extension, that the validity window includes the current date, and that the issuer matches the expected certificate authority. This command examines a file; it does not prove that NGINX is serving that file, so pair it with the remote s_client test.

Exercise the services users actually need

• Open the web interface through the canonical FQDN.
• Clone and fetch a test repository over HTTPS.
• Sign in and submit a form to exercise CSRF and forwarded-header handling.
• Push and pull from the container registry if it is enabled.
• Check webhook, runner, and API integrations that use the external URL.

Run these checks from a client outside the GitLab host when possible. A local test can succeed while an external firewall, DNS view, or load balancer remains misconfigured.

Private and air-gapped installations

Let's Encrypt's normal public challenge is not suitable for a hostname that cannot resolve publicly or cannot accept public validation traffic. Disable Let's Encrypt, use a certificate issued by an internal CA or another ACME service reachable from the private network, and distribute the issuing CA certificate to every client that must trust GitLab.

Use a DNS name rather than an IP address even when all users are internal. The name provides a stable certificate identity and allows the address to change without replacing every client configuration. For an entirely disconnected environment, transfer the certificate and full chain through your approved offline process, store them in /etc/gitlab/ssl, protect the key, and apply the configuration with gitlab-ctl reconfigure.

Internal certificates also affect runners, automation hosts, package managers, and container engines. Install the internal root CA in each trust store that makes GitLab connections; otherwise those clients may report an unknown issuer even though browsers on managed desktops work correctly.

Helm deployments: configure Kubernetes TLS instead

Do not copy Omnibus paths such as /etc/gitlab/ssl into a Helm deployment. In Kubernetes, TLS is represented by ingress or Gateway settings. Reference an existing Kubernetes Secret containing the certificate and key, or use cert-manager automation with a Let's Encrypt HTTP-01 solver when the ingress is publicly reachable.

The ingress or Gateway should expose the public hostname, select the TLS secret, and route traffic to the GitLab services created by the chart. Ensure the HTTP-01 solver can receive requests on port 80 if you use that challenge type. Certificate renewal then belongs to Kubernetes and cert-manager rather than gitlab-ctl reconfigure. Validate the resulting secret, ingress events, and externally served chain with the same OpenSSL approach used for any public endpoint.

Self-compiled GitLab installations

Source-built GitLab instances do not use the Omnibus generated configuration or its default certificate directory. Set the GitLab URL to HTTPS in the source installation's configuration and adapt the documented gitlab-ssl NGINX example. Place the certificate and key where that NGINX configuration expects them, ensure the worker can read the key, and reload NGINX after changes.

Best Value

Sale

Under Desk Cable Management Tray No Drill, Metal Mesh Cable Management Under Desk with Clamp Mount, 2 Hole Cable Tray with Wire Management and Cord Organizer for Home Office Standing Desk

• 【No Drill Mounted】Cable management tray can be assembled in as little as 3 minutes or less-simply. Side clips easily clampe the edge of desk, pass through the holes on the sides, and secure excess cables with baskets. Desk cable management supports inward or outward installation to meet your needs in different scenarios, and provides you with great convenience when collecting and organizing wires.
• 【Rubber Pad Protects Desk】Wire organizer under desk built-in soft rubber pads on the clamp protect your desk from scratches, so you will not damage your furniture or office.
• 【Sturdy and Beautiful】Cord management under desk is made of high-quality carbon steel and holds about 15 lbs. The wire basket has 2 holes on each side of the tray to enable your cables to pass freely. Cable baskets are suitable for desk thickness use from 0.4" to 2.4".
• 【Space Saving & Keep Organized】Desk cable management tray holds all your power cords, outlet strips, USB hubs and computer transformers hidden from your feet, and the data cables will not enter the vacuum cleaner to keep your desk clean and tidy. Desk wire organizer is also suitable for use in the kitchen and outdoors.
• 【Reduce Safety Risks】Cable tray under desk keeps all plugs away from your kids, no more worry about tripping. Using 2 holes wire tray saves extra space, helps you easily cabling and wire protection. The mesh design is not easy to accumulate dust, but avoids safety accidents caused by messy wires.

$13.89

Buy on Amazon

The same principles still apply: the certificate must cover the public FQDN, the full chain must be served in the correct order, and a proxy must forward the original host and HTTPS state if it terminates TLS upstream.

Troubleshoot common failures

ACME validation says the domain cannot be reached

• Confirm that public DNS returns the intended address, including both authoritative records and any IPv6 record.
• Verify that TCP 80 and 443 reach the machine or proxy that serves the challenge.
• Check NAT, cloud security groups, host firewalls, and another web server occupying the ports.
• Make sure the requested hostname exactly matches external_url.

Correct the network path before repeatedly running reconfigure. Use an ACME staging endpoint while troubleshooting to avoid production rate limits.

The browser reports an incomplete chain

Rebuild the certificate file with the server certificate first, followed by every intermediate and then the root when required by the issuing authority. Reload NGINX after replacing the file and verify the live endpoint; inspecting only the local file cannot reveal whether the running service loaded the new chain.

The certificate is for the wrong name

Inspect the subject-alternative-name list with OpenSSL. Request a certificate containing the exact canonical hostname, update DNS or external_url consistently, and remove stale alternate names from bookmarks and integrations. A wildcard certificate can cover subdomains only within the scope stated by its name; it does not automatically cover the bare parent domain.

Reconfigure fails because the key is encrypted

Set gitlab_rails['nginx']['ssl_password_file'] to a protected passphrase file, or replace the key with one managed according to your organization's key-protection policy. NGINX cannot stop during reconfigure and wait for an interactive password.

Users see an HTTPS loop or 422 response behind a proxy

Confirm that the proxy sends Host, X-Forwarded-Ssl, X-Forwarded-For, and X-Forwarded-Port with the public values. Keep external_url set to HTTPS while bundled NGINX listens on HTTP. Remove conflicting redirect rules and prevent direct access to the backend that would bypass the trusted proxy.

The new certificate is not visible

Check the file path, permissions, hostname-based filename convention, and chain contents. For content-only changes, run sudo gitlab-ctl hup nginx; also run sudo gitlab-ctl hup registry when the registry certificate changed. If configuration values changed, use sudo gitlab-ctl reconfigure instead.

Helm administrators are looking for Omnibus files

Stop looking for /etc/gitlab/gitlab.rb or /etc/gitlab/ssl in a pod. Inspect the ingress or Gateway resource, the referenced Kubernetes TLS secret, and cert-manager events. The deployment model determines the certificate path.

Security and operational considerations

Understand HSTS

GitLab documents HTTP Strict Transport Security (HSTS) as enabled by default for the main application, with a default max_age of 63,072,000 seconds, or two years. HSTS tells compatible browsers to use HTTPS for the hostname during that period. Test the complete HTTPS path, including subdomains and administrative access, before enabling any policy that could make an incorrectly configured HTTP endpoint difficult to reach.

Monitor expiry and renewal

Automatic ACME renewal removes routine copying but does not remove the need for monitoring. Alert before the 90-day certificate lifetime is exhausted, record the last successful renewal, and test the external endpoint rather than trusting only a local file timestamp. For manual certificates, schedule renewal, chain assembly, permissions, reloads, and post-renewal OpenSSL checks as one runbook.

Protect private keys and proxy trust

Mode 600 on a private key is a baseline, not a complete security plan. Limit shell access, backups, configuration-management logs, and proxy hosts that can read the key. On a reverse-proxy design, allow only trusted proxy addresses to reach the HTTP backend and ensure clients cannot supply forged forwarding headers.

Which SSL method should you use?

For a normal public Omnibus installation, start with the HTTPS external_url, verify public DNS and ports 80/443, and let ACME manage renewal. Select manual certificates when public validation is impossible or your PKI requires it. Select proxy termination when another device is already the controlled public entry point, and then treat forwarded headers and backend isolation as essential parts of the HTTPS configuration.

Quick Recap

SaleBestseller No. 1

Compressed Air Duster,130000RPM Super Power Cordless Air Duster,Rechargeable Brushless Blower,3 Gear Adjustable Blower with LED Light,Dust Remover for Computer/House/Outdoor/Car

$21.59

Bestseller No. 2

EVEO® Screen Cleaner Spray Kit (Streak-Free) TV Screen Cleaner for Smart TV, Lcd, LEd, Oled | Computer Screen Cleaner Spray and Wipe Microfiber Cloth - TV, Monitor, Laptop, iPad, Car - 6.7oz 1 Pack

$15.97

SaleBestseller No. 3

BladeHawks RGB Gaming Mouse Pad Extra Large Extended 31.5x12 Inch-Black | LED mouse pad with 14 lighting modes, covers keyboard & mouse, anti-slip rubber base, waterproof surface, USB powered

$13.99

SaleBestseller No. 4

Vaydeer Wrist Rest for Keyboard and Mouse, Computer Ergonomic Wrist Support Pad, Soft Memory Foam Arm Cushion for Desk, Palm Hand Office Laptop Typing

$15.99

SaleBestseller No. 5

Under Desk Cable Management Tray No Drill, Metal Mesh Cable Management Under Desk with Clamp Mount, 2 Hole Cable Tray with Wire Management and Cord Organizer for Home Office Standing Desk

$13.89

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.