I had discovered something funny today. So, I have Kali Linux and I am trying to fully update the system using the repo http://http.kali.org/kali. All is good and well until I get 403 denied for backdoor-factory and mimikatz. At first I thought it was a server configuration error and so ignored it, but then I got curious and decided to pop the URLs into Firefox. Sure enough, my university blocks these specific URLs, but not anything else in the repo.

I decided to check out if I could load the URLs in https (yes, I knew it was a long shot as most (afaik) APT servers don't even support https at all) and found out it does work, but only when accepting the certificate for archive-8.kali.org. (yes, I know invalid certs aren't good, but I figured if it is using GPG to check the validity and it uses http with no encryption anyway, then why not).

Also, I know I can just use https://archive-8.kali.org/kali in place of the old url and have done so, but the reason I asked about accepting invalid certs is for if this solution of just switching domains is impossible.

2 Answers 2


You can configure certain parameters for the HTTPS transport in /etc/apt/apt.conf.d/ — see man apt.conf (section "THE ACQUIRE GROUP", subsection "https") for details.
There is also a helpful example over at the trusted-apt project.

For example, you can disable certificate checking completely:

// Do not verify peer certificate
Acquire::https::Verify-Peer "false";
// Do not verify that certificate name matches server name
Acquire::https::Verify-Host "false";

… or just for a specific host:

Acquire::https::repo.domain.tld::Verify-Peer "false";
Acquire::https::repo.domain.tld::Verify-Host "false";

These options should be placed in a newly created file in /etc/apt/apt.conf.d/ so they won't interfere with options installed by official packages (which will create separate files of their own).
The filename determines the order in which the option files are parsed, so you'll probably want to choose a rather high number to have your options parsed after the ones installed by other packages. Try 80ssl-exceptions, for example.

  • This works well when I tested the specific host part, I just was confused when I tried it and didn't realize that I was supposed to remove the brackets to produced a result such as Acquire::https::repo.domain.tld::Verify-Peer "false"; Acquire::https::repo.domain.tld::Verify-Host "false"; Oct 20, 2016 at 14:57
  • @SenorContento You're right, I quoted the wrong example there. I've removed the incorrect brackets now.
    – n.st
    Oct 20, 2016 at 15:04
  • thanks your answer saved my day Apr 4, 2021 at 12:01
  • 9
    apt -o "Acquire::https::Verify-Peer=false" update
    – mr.wolle
    Apr 12, 2022 at 8:40

For a temporary solution you can do:

apt -o "Acquire::https::Verify-Peer=false" update
apt -o "Acquire::https::Verify-Peer=false" install curl
  • For me https did not work but http did, i.e. my command was Acquire::http::Verify-Peer=false Nov 29, 2023 at 14:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .