How not to Automatically add registry hostname to the to alt_name of the LetsEncrypt certificate

Hello guys,

We have deployed external container registry with gitlab auth endpoint. But letsencrypt is automatically trying to add certificate on external registry that hosted on different location. when letsencrypt trying to add new certificate on registry it fails to authenticate. It is actually added feature on 11.0.0. How to revert this change on gitlab community edition 15.0.0.

Hi,

I don’t think Gitlab have thought about this type of scenario. As per the docs: GitLab Container Registry administration | GitLab

I’m therefore assuming that you have letsencrypt enabled for your basic installation of Gitlab, and therefore, any other configuration options using https in the url (for example container registry), then it’s attempting to generate for that as well. Unfortunately, the docs don’t have an option for registry_letsencrypt['enable']=false which would have been ideal in such a situation.

I think your only two options are:

  1. Use letsencrypt['enable'] = false and use alternative commercial certificates for your Gitlab install, or generate certificates if you have an internal CA. Worst case self-signed to generate but not ideal.
  2. Create an issue here for Gitlab to potentially offer a solution similar to what I suggested: https://gitlab.com/gitlab-org/gitlab/-/issues

Option 2 won’t help you immediately, but would be nice for the future. Option 1 would help you as of now, but just means you need to sort out an alternative SSL certificate.

I have been unable to find any other solution for this right now. Maybe someone from the Gitlab team will see this and be able to offer some insights/solutions if something does exist.

2 Likes

Hello,

I have commented out the alt_names certificate checking function on the file certificate.rb both production and staging section.
/opt/gitlab/embedded/cookbooks/letsencrypt/resources/certificate.rb
Certificate alt_names has the value external registry domain(registry_external_url) that we have configured on the gitlab.rb. After comment out those sections we have no more error during reconfiguration gitlab. But we don’t know this is the correct approach for this issue. Could anyone please check it?

acme_certificate 'staging' do
#    alt_names new_resource.alt_names unless new_resource.alt_names.empty?**
    key_size new_resource.key_size unless new_resource.key_size.nil?
    group new_resource.group unless new_resource.group.nil?
    owner new_resource.owner unless new_resource.owner.nil?
    chain "#{new_resource.chain}-staging" unless new_resource.chain.nil?
    contact contact_info
    crt "#{new_resource.crt}-staging"
    cn new_resource.cn
    key "#{new_resource.key}-staging"
    dir new_resource.acme_staging_endpoint
    wwwroot new_resource.wwwroot
    sensitive true
  end

  ruby_block 'reset private key' do
    block do
      node.normal['acme']['private_key'] = nil
    end
  end

  if ::File.file?(new_resource.key)
    production_key = OpenSSL::PKey::RSA.new ::File.read new_resource.key
    production_key_size = production_key.n.num_bits

    if production_key_size != target_key_size
      file new_resource.key do
        action :delete
      end
      file new_resource.crt do
        action :delete
      end
    end
  end

  acme_certificate 'production' do
#    alt_names new_resource.alt_names unless new_resource.alt_names.empty?**
    key_size new_resource.key_size unless new_resource.key_size.nil?
    group new_resource.group unless new_resource.group.nil?
    owner new_resource.owner unless new_resource.owner.nil?
    chain new_resource.chain unless new_resource.chain.nil?
    contact contact_info
    crt new_resource.crt
    cn new_resource.cn
    key new_resource.key
    dir new_resource.acme_production_endpoint
    wwwroot new_resource.wwwroot
    notifies :run, 'execute[reload nginx]'
    sensitive true
  end
end

No not really, since when you upgrade that cookbook will be replaced and the problem will occur again. As I said you will need to raise an issue with Gitlab to get it resolved properly, or simply don’t use LetsEncrypt and use alternative certificates, purchased commercial ones, or ones from your own CA.

1 Like