GOGS issue after SSL renewal

We have GOGS installed in containerized apache server system with reverse proxy and it was functional for some time now until yesterday. We started seeing this issue when we updated the SSL certificate and since then, it is taking us to the default ssl config file rather than opening up GOGS. Any suggestion to fix this issue would be appreciated.

Domain: ammahub.com

Quick Note: We also have another git server installed on our subdomain, idea, and that is functional without issues, though we are seeing SSL renewal issues.

I never used Apache but that sounds like a config problem on the reverse proxy side because the connection from reverse proxy to Gogs is direct.

Mind sharing your apache config see if there is obvious misconfiguration?

1 Like

Thanks for your response. This site was functional just like the other one until a couple of days ago including the SSL. Having this issue since SSL renewal.

Git server is on its own in a container and then linked to a lamp container where this domain’s vhost file is located.

I have been adjusting this file for some time to get at least the non-ssl site working. This is the current version that I have.

<VirtualHost *:80>

 ServerName ammahub.com
 ServerAlias www.ammahub.com
 ServerAdmin [email protected]

 Redirect 301 / https://www.ammahub.com

<VirtualHost *:443>

 ServerName ammahub.com
 ServerAlias www.ammahub.com
 ServerAdmin [email protected]

 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined

 ProxyRequests Off

 <Proxy *>
    Order deny,allow
    Allow from all
 </Proxy>

 ProxyPass / #######
 ProxyPassReverse / ######

 <Location />
    Order allow,deny
    Allow from all
 </Location>

A quick clarification - I just checked again and the recent conf file results in a functional www site, though I am still having issues with SSL and the non-www site.

Hmm :thinking: Are you using VPS or is there a firewall-like service in front of your Gogs instance (e.g. Cloudflare)?

It is possible that:

  1. Your local browser hasn’t been able to pick up the new certificate and still thinking the site is using the old-expired certificate.
  2. The service provider might need time to update over its all CDN nodes.

Thanks again for suggesting possible issues.

I dropped in this post after checking out all possible reasons including the two mentioned.

Blockquote
our local browser hasn’t been able to pick up the new certificate and still thinking the site is using the old-expired certificate. The service provider might need time to update over its all CDN nodes.

Took care of cache and also tried in different machines, browsers under different modes. I doubt that this is the reason.

Blockquote
Hmm :thinking: Are you using VPS or is there a firewall-like service in front of your Gogs instance (e.g. Cloudflare)?

I doubt that these are the issues as I had a fully functioning site as can be seen from the expired certificate still in place. For that matter, this system includes other live secure sites such as, https://aioradar.com, https://www.searchgiggle.com/spacegigglicious/ to name a few that are fully functional.

What surprises me is that the permanent redirect at the top is not working? If you have other ideas to make this redirect and SSL functional, please do share.

Example config I use for my setup. (Apache2 reverse proxy for web-interface running on localhost:3000)

HTTP port 80, permanent redirect to HTTPS port 443

<IfModule mod_rewrite.c>
<VirtualHost _default_:80>
    ServerName git.example.com
    RewriteEngine On
    RewriteCond %{SERVER_NAME} =git.example.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
</IfModule>

HTTPS port 443

<IfModule mod_ssl.c>
<VirtualHost _default_:443>
    ServerName git.example.com
    ProxyPass / http://[::1]:3000/
    ProxyPassReverse / http://[::1]:3000/
    ProxyPreserveHost On
    ErrorLog /var/log/apache2/git.example.com-error.log
    CustomLog /var/log/apache2/git.example.com-access.log combined
    SSLEngine on
    <FilesMatch "\.(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>
    SSLCertificateFile /etc/letsencrypt/live/git.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/git.example.com/privkey.pem
    Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>
2 Likes

Thanks, @netravnen. Let me play with the conf file aligning with your suggestion to see whether that resolves the issue.

Personally. I always enable SSL whenever possible. With lets-encrypt the preferred choice for Internet-accessible web-frontends. And don’t enable plain HTTP access :arrow_right: HTTP instant redirect to HTTPS as in the prior posted example. (Either HTTPS works. Or the web-frontend becomes in-accessible. Results in fewer points of failure to debug. Should I mistakenly break the config file :laughing: )

@netravnen: I followed your suggestion and implemented the new conf file. It looks like the issue persists.

ServerName ammahub.com
RewriteEngine On
RewriteCond %{SERVER_NAME} = ammahub.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
ServerName ammahub.com
ProxyPass / ######
ProxyPassReverse / #######
ProxyPreserveHost On
ErrorLog /var/log/apache2/ammahub.com-error.log
CustomLog /var/log/apache2/ammahub.com-access.log combined
SSLEngine on
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
SSLCertificateFile /etc/letsencrypt/live/ammahub.com-0002/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ammahub.com-0002/privkey.pem
#Include /etc/letsencrypt/options-ssl-apache.conf

Blockquote
And don’t enable plain HTTP access :arrow_right: HTTP instant redirect to HTTPS as in the prior posted example. (Either HTTPS works. Or the web-frontend becomes in-accessible. Results in fewer points of failure to debug. Should I mistakenly break the config file :laughing:

Noted. I go through different iterations and the one presented was the recent config file. For that matter, idea.ammahub.com uses a slightly different config file, though the outcome is not any different when it comes to SSL.