All urls in this version are preceded by an IP address in the txt or host file:

  0.0.0.0 example.com – It will forward the domain example.com to the address 0.0.0.0 (but not for its subdomains).

  127.0.0.1 example.com – will return the address 127.0.0.1 for the domain example.com (but not for its subdomains).

 All urls in this version no are preceded by an IP address in the txt or host file:

  example.com

^{Our users have reported to us that some devices give an error if the url is preceded by an IP address.}

 All urls from this version of the **AdGuard** list appear in the hosts file as follows:

  ||example.org^ – blocks access to the domain example.org and all its subdomains

  @@||example.org^ – unlocks access to the example.org domain and all its subdomains.

  /REGEX/ – blocks access to domains matching the specified regular expression. For example, the rule /example.*/ will block hosts matching the example.*

  $ – This is the delimiter, which indicates that the rest of the rule is a modifier. Modifiers must be placed at the end of the rule after the character and separated by commas. For example, the modifiers must be placed at the end of the rule after the character and separated by commas. ||example.org^$important.

  $important – The modifier applied to a rule increases its priority over any other rule without the modifier. Even above the basic exception rules.

  * – the wildcard character. It is used to represent any set of characters. It can also be an empty string or a string of any length.

  ^ – the separator character. Unlike browser ad blocking, there is nothing to separate in a hostname, so the only purpose of this character is to mark the end of the hostname.

  | – a pointer to the beginning or end of the host name. The value depends on the location of the character in the mask. For example, the rule ample.org| corresponds to example.org, but not to example.org.com. |example corresponds to example.org but not to test.example.org

^{The instructions are current as of AdGuard Home v0.107.2. AdGuard supports older versions. The instructions it supports AdGuard Home.}

 All urls for this version of the list appear in the hosts file in the following way

  # comment – just a comment

  ! comment – just a comment

Use with Pi-Hole :

1. Copy the link to the Pi-hole format of the desired list (from the corresponding table below).
2. Add the URL to your Pi-hole block lists (Login > Groups management > Lists > Paste the URL of the list in the "Address" field, add a comment > Click "Add ").
3. Update Gravity (Tools > Update Gravity > Click on "Update " )

  ^{Current instructions as of Pi-hole 5.2.4. Instructions may be slightly different at present. Instructions will be updated when version 6 is released.}

Use with AdGuard Home :

1. copy the link to the AdGuard format corresponding to the desired list (from the corresponding table below).
2. Add the URL to your AdGuard block list (Login > Filters > DNS block lists > Add block list > Add a custom list > Enter name > Paste the URL of the copied link).
3. The list is automatically activated and is ready to start blocking.

  ^{Instructions are current as of AdGuard Home v0.107.2}

Installing a free SSL certificate with CertBot:

1️⃣ We update the list of packages.

sudo apt update && sudo apt upgrade

2️⃣ Install the Certbot package

sudo apt install certbot

Cerbot Documentation:

3️⃣ In this section we are going to see the most important options of the command. You can choose the options that you consider most convenient.

Certbot supports a lot of command line options. Here’s the full list, from certbot --help all:

👉 3.1 You can add as many domains as you wish with the --domain variable. Example:

👉 3.2 You can change the variable --rsa-key-size to the size:

👉 3.3. --csr The csr variable and a .cnf file can perform the following functions. Currently --csr only works with the certonly subcommand.

• Follow this tutorial that I have added separately to create the csr

👉 3.4. --config-dir You can configure the configuration file with the variable.

• The certificate specific configuration options must be set in the .conf and I attach an example:

👉 3.5. --test-cert, --staging Use the Let's Encrypt staging server to obtain or revoke test (invalid) certificates; equivalent to --server acme-staging

👉 3.6. --hsts Add the Strict-Transport-Security header to every HTTP response. Force the browser to always use SSL for the domain.

👉 3.7. --key-type {rsa,ecdsa}. Type of generated private key. Only ONE per invocation can be provided at this time.

👉 3.8. --quiet Silence all output except errors.

👉 3.9. --cert-name Certificate name to apply. This name is used by Certbot for housekeeping and in file paths; it doesn't affect the content of the certificate itself.

👉 3.10 --debug Show tracebacks in case of errors

👉 3.11 --dry-run Perform a test run against the Let's Encrypt staging server, obtaining test (invalid) certificates but not saving them to disk.

👉 3.12 --dns-cloudflare Obtain certificates using a DNS TXT record (if you are using Cloudflare for DNS).

👉 3.13. --server Choose the ACME Directory Resource URI for your server.

👉 3.14. --elliptic-curve (default: secp256r1) The SECG elliptic curve name to use.

For the choice of the key to be chosen the difference in the definition of the base point has two important consequences:

• The secpXXXk1 curve has a higher computational efficiency than the secpXXXr1 curve. This is because the base point of the secpXXXk1 curve is a generation point, which means that it can be used to generate all the other points of the curve. The base point of the secpXXXr1 curve, on the other hand, is not a generation point, so more operations need to be calculated to generate all the other points of the curve.
• The secpXXXr1 curve has higher security than the secpXXXk1 curve. This is because the base point of the secpXXXr1 curve is a more random point than the base point of the secpXXXk1 curve. This makes it more difficult for attackers to find points on the curve that are not in the set of generation points. In general, the secpXXXXk1 curve is a good choice for applications that require computational efficiency, while the secpXXXr1 curve is a good choice for applications that require security.

Examples of applications that could use each curve:

Run the following command modifying the valid email and options as you see fit for your example.

This example is for acquiring a Wildcard certificate:

certbot certonly --manual --preferred-challenges=dns --rsa-key-size 4096 --email usuario@ejemplo.com --agree-tos
--server https://acme-v02.api.letsencrypt.org/directory -d "*.your_domain"

4️⃣ Finally, it will ask to make an _acme-challenge TXT record in our name server provider with the content it tells us: With cerbot, when using the dns challenge, certbot will ask you to place a TXT DNS record with specific contents under the domain name consisting of the hostname for which you want a certificate issued, prepended _acme-challenge. For example, for the domain example.com, a zone file entry would look like:

_acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM"

It creates the following files, in the directory /etc/letsencrypt/live/:

• fullchain.pem – your SSL certificate encrypted in PEM.
• privkey.pem – your private key encrypted in PEM.

To check if the certificate will self-renew:

• Renewal test (simulación):certbot renew --dry-run
• Check the status of the Certbot timer service: systemctl status certbot.timer
• To renew a certificate: certbot renew
  • To force self-renewal: --force-renewal
• To list jobs: systemctl list-timers --all Debe aparecer el siguiente configurado para la renovación automática: certbot.timer - certbot.service
• Listing certificates: certbot certificates

To revoke a certificate:

• Delete a certificate completely: certbot delete --cert-name example.com --reason keycompromise
• From the account for which the certificate was issued: certbot revoke --cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem --reason keycompromise
• Using the certificate's private key: certbot revoke --cert-path /PATH/TO/cert.pem --key-path /PATH/TO/key.pem --reason keycompromise

If you do not want to follow all these steps, you can obtain the certificate with ZeroSSL, but the wildcard certificate is charged.

Steps you can follow to create a self-signed RSA certificate using OpenSSL with SHA-512 and Subject Alternative Names (SAN).

To learn more about on useful openssl commands for certificates:

1. We update the list of packages.

sudo apt update && sudo apt upgrade

2. Make sure you have OpenSSL installed on your system before proceeding. Install the openssl package:

sudo apt install openssl

3. Create the directory where we want to store the certificates:

mkdir certs &&\
cd certs/

4. Create certificate with the following command, changing the certificate path or leave the name of the .key and dot crt to store it in the directory:

   4.1 Generate an RSA private key:

   openssl genpkey -algorithm RSA -out privkey.key -pkeyopt rsa_keygen_bits:2048

   4.2 Next, we will create a certificate request (CSR) which will contain the certificate information:

   vi csrconfig.cnf

   [req]
   distinguished_name = req_distinguished_name
   req_extensions = v3_req
   
   [req_distinguished_name]
   commonName = your website domain name
   organizationName = Your Company Name
   countryName = ES
   
   [v3_req]
   subjectAltName = @alt_names
   
   [alt_names]
   DNS.1 = example.com
   DNS.2 = www.example.com

   4.3 We generate the self-signed certificate with the CSR data:

   openssl req -new -key privkey.key -out chain.csr -sha512 -config csrconfig.cnf
   

   4.4 Create self-signed certificate in PEM format:

   openssl x509 -req -in chain.csr -signkey privkey.key -out fullchain.pem -sha512 -days 365 -extfile csrconfig.cnf -extensions v3_req
   

   4.5 After creating the self-signed certificate, we can verify the content of the certificate if it has been created correctly:

   openssl x509 -in fullchain.pem -text -noout

 Page to check your selfhosted from fivefilters

 Page to check your selfhosted from d3ward

 Page to check your selfhosted from canyoublockit

 Page to check your selfhosted from No more ads

 Page to check your selfhosted from AdBlock Tester

 Page to check encryption of 1.1.1.1 de Cloudflare

 Page to check encryption of Tenta VPN Browser

 Page to check encryption of Cloudflare

1. Secure DNS: a technology that encrypts DNS queries and includes DNS-over-TLS and DNS-over-HTTPS.
2. DNSSEC: a technology designed to verify the authenticity of DNS queries.
3. TLS 1.3: the latest version of the TLS protocol that includes many improvements and closes security holes from previous versions.
4. Encrypted SNI: stands for Server Name Indication encryption that reveals the hostname during a TLS connection. This technology aims to ensure that only the IP address can be leaked.

^{The only browser that supports all four technologies is Firefox.}

  network.security.esni.enabled - pulsamos en el + y se ponga en true.

  network.trr.mode – (valor 2)

  network.trr.uri – valor en la web Mozilla.

  HTTPS-Only Mode - pulsamos en el + y se ponga en true.

 Page to check DNSSEC

 Page to check DNSSEC encryption

 Page to check DNS leakage