self signed sertificate

Hi,
I have managed to hit the limit of letsenrypt so i need to wait for week…
Is there anyway to apply a self signed certificate for this time? I have found any tutoral or suggestion how to do it, if it is all possible.
thanks
Andrew

Sure you can use a self signed certificate. But mostly all browsers and application will complain about it. Some client applications even did not work as the certificate is not trusted

It would be a home installed nextcloud to be reached by ios nextcloud app. I would give a try. How do i do it with dietpi RP3B ?

Depends on the web server used. Which one you have installed?

I’m having trouble getting this working on my dietpi.

I followed this guide but removed the CA line. I have this working on another raspberry pi running raspberry pi os. Using the same scripts but changing the FQDN results in https not being available on the dietpi. The site does not redirect to https and if https is specified then a connection cannot be made to the server. No firewall is enabled.

I noticed that there are some extra config files in /etc/lighttpd/conf-enabled on dietpi compared to a regular pihole install, but I haven’t full dug through everything yet. I tried removing the two 99-dietpi-pihole conf files but that did not change the behavior.

I was hoping someone else who has run into this knows the fix.

Here is my setup. I use a different FQDN than “pihole.example.com”.

external.conf

$HTTP["host"] == "pihole.example.com" {
  # Ensure the Pi-hole Block Page knows that this is not a blocked domain
  setenv.add-environment = ("fqdn" => "true")

  # Enable the SSL engine with a LE cert, only for this specific host
  $SERVER["socket"] == ":443" {
    ssl.engine = "enable"
    ssl.pemfile = "/etc/lighttpd/ssl/pihole.example.com/combined.pem"
    ssl.honor-cipher-order = "enable"
    ssl.cipher-list = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"
    ssl.use-sslv2 = "disable"
    ssl.use-sslv3 = "disable"       
  }

  # Redirect HTTP to HTTPS
  $HTTP["scheme"] == "http" {
    $HTTP["host"] =~ ".*" {
      url.redirect = (".*" => "https://%0$0")
    }
  }
}

Script to generate ssl certificate.

pnCert=/etc/lighttpd/ssl/pihole.example.com
fnCert=$pnCert/combined.pem

mkdir -p $pnCert
openssl req -new -x509 -newkey rsa:4096 -keyout $fnCert -out $fnCert -days 365 -nodes -subj "myDeets"
chown www-data:www-data $fnCert
chown www-data -R $pnCert
chmod 0600 $fnCert

systemctl restart lighttpd.service

Files present in /etc/lighttpd/conf-enabled in dietpi+pihole.

10-fastcgi.conf
15-fastcgi-php.conf
99-dietpi-pihole.conf
99-unconfigured.conf
99-dietpi-pihole-block_public_admin.conf

Files present in /etc/lighttpd/conf-enabled on raspberry pi os+pihole.

10-fastcgi.conf
15-fastcgi-php.conf
90-javascript-alias.conf

i use the standard web server provided by dietpi for nextcloud

willis936
what is the reason for creating a self signed certificate and not using dietpi-letsencrypt. I highly recommend to use an official certificate if your system is reachable from internet.

As well, pls don’t remove any DietPi config files. DietPi is going to setup the web server a different way than a plain PiHole installation would do. This is to allow other web server apps (like NextCloud) to work next to PiHole. Therefore you can’t compare the availability of config files. As well this has nothing to do with DietPi or Raspberry OS. (Btw DietPi is a Raspberry OS). It’s simply the way how thinks are installed and configured.

eglider86
Did you activated HTTPS already before and just like to replace the certificate with a self signed one?

Let’s check configuration files

ls -la /etc/lighttpd/conf-{available,enabled}

@Joulinar This is for a redundant pi-hole setup behind a NAT. The HTTP/S forwarded IP is not on this raspberry pi. In the context of recent Wi-Fi exploits I no longer trust unencrypted LAN traffic. SSL certs can be checked once per client. Browsers remember accepted certs after prompted once and no longer prompt. I’ll still update the cert on a schedule.

ok but if you really worry about someone being able to read your local http traffic, you should more worry about what these guy can do as well. Like manipulate your local unencrypted DNS traffic. Or do you encrypt the DNS traffic between clients and PiHole?

But ok it’s up to you.

[hr]
On a standard DietPi system HTTPS on Lighttpd is done by 2 config files

50-dietpi-https.conf # activate HTTPS
98-dietpi-https_redirect.conf # redirect port 80 > 443

they should be located at /etc/lighttpd/conf-available

both files have following content

50-dietpi-https.conf

# Based on: https://ssl-config.mozilla.org/#server=lighttpd
server.modules += ( "mod_openssl" )
# IPv4
$SERVER["socket"] == ":443" {
        protocol = "https://"
        ssl.engine = "enable"

        # pemfile is cert+privkey, ca-file is the intermediate chain in one file
        ssl.pemfile = "/etc/letsencrypt/live/example.com/combined.pem"
        ssl.ca-file = "/etc/letsencrypt/live/example.com/fullchain.pem"

        # For DH/DHE ciphers, dhparam should be >= 2048-bit
        #ssl.dh-file = "/path/to/dhparam.pem"
        # ECDH/ECDHE ciphers curve strength, see "openssl ecparam -list_curves"
        ssl.ec-curve = "secp384r1"

        # Environment flag for HTTPS enabled
        setenv.add-environment = ( "HTTPS" => "on" )

        # Intermediate configuration, tweak to your needs
        ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2", "Options" => "-SessionTicket")
        ssl.cipher-list = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
        ssl.honor-cipher-order = "disable"
        ssl.disable-client-renegotiation = "enable"
}
# IPv6
$SERVER["socket"] == "[::]:443" {
        protocol = "https://"
        ssl.engine = "enable"

        # pemfile is cert+privkey, ca-file is the intermediate chain in one file
        ssl.pemfile = "/etc/letsencrypt/live/example.com/combined.pem"
        ssl.ca-file = "/etc/letsencrypt/live/example.com/fullchain.pem"

        # For DH/DHE ciphers, dhparam should be >= 2048-bit
        #ssl.dh-file = "/path/to/dhparam.pem"
        # ECDH/ECDHE ciphers curve strength, see "openssl ecparam -list_curves"
        ssl.ec-curve = "secp384r1"

        # Environment flag for HTTPS enabled
        setenv.add-environment = ( "HTTPS" => "on" )

        # Intermediate configuration, tweak to your needs
        ssl.openssl.ssl-conf-cmd = ("MinProtocol" => "TLSv1.2", "Options" => "-SessionTicket")
        ssl.cipher-list = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
        ssl.honor-cipher-order = "disable"
        ssl.disable-client-renegotiation = "enable"
}

98-dietpi-https_redirect.conf

$HTTP["scheme"] == "http" {
        # Capture vhost name with regex conditional %0 in redirect pattern
        # Must be the most inner block to the redirect rule
        $HTTP["host"] =~ ".*" {
                url.redirect = (".*" => "https://%0$0")
        }
}

make sure /etc/lighttpd/lighttpd.conf contains the following 2 mods

        "mod_setenv",
        "mod_redirect",

to activate the config

lighty-enable-mod dietpi-https
lighty-enable-mod dietpi-https_redirect
systemctl restart lighttpd

There is benefit in hiding the admin interface password and the traffic logs. Eavesdropping Wi-Fi is much more reasonable to accomplish than a MITM (which I think would require a stronger Wi-Fi signal at the clients from the attacker than the WAP). Correction: I’m definitely wrong here and unencrypted DNS over Wi-Fi is bad.

I don’t think software is really there for DNSSEC or DoT to run on most DNS clients, this could just be my ignorance though.

I don’t see

50-dietpi-https.conf # activate HTTPS
98-dietpi-https_redirect.conf # redirect port 80 > 443

in /etc/lighttpd/conf-available. Here is a list of files in /etc/lighttpd/conf-available.

05-auth.conf
10-accesslog.conf
10-cgi.conf
10-dir-listing.conf
10-evasive.conf
10-evhost.conf
10-expire.conf
10-fastcgi.conf
10-flv-streaming.conf
10-no-www.conf
10-proxy.conf
10-rewrite.conf
10-rrdtool.conf
10-simple-vhost.conf
10-sockproxy.conf
10-ssi.conf
10-ssl.conf
10-status.conf
10-userdir.conf
10-usertrack.conf
11-extforward.conf
15-fastcgi-php.conf
90-debian-doc.conf
99-dietpi-pihole-block_public_admin.conf
99-dietpi-pihole.conf
99-unconfigured.conf

I’ll I try uninstalling/reinstalling pihole and the LLSP stack.

Update: no change in available configs after a LLSP and Pi-Hole uninstall+reinstall.


Update: manually making those two conf files and updating the cert/CA lines fixed the issue. Cheers! Thank you for the help.

Yes files are not present by default, they are generated by dietpi-letsencrypt. That’s why I posted both files and it’s content.

I don’t think software is really there for DNSSEC or DoT to run on most DNS clients

Modern web browser allow to configure DoT and/or DoH inside their configuration (independent from client).

Thanks for the input, but i can not get it worked. I think i understand the my scenario now a bit better.
So now the major problem as i see, that because of getting lost with running certbot, i have reached the limit of certificates. So correct me if i am wrong, now at least i must have at least valid one for my domain. But everytime i am running dietpi-launcher then dietpi-DDNS then dietpi-letsencrypt and certbot, it tries to download a brand new certificate but for some reason it is not applied. Then i saw in the debug log it has crteated several copy of my domin like “domain-001.cert” and “domain-002.cert” beside the "domain.cert. I have removed all tried agian but since i reached my limit no success.
My question is the following. Since certificate has been issued for my domain what is the way to download this and apply for my dietpi nextcloud?

My question is the following. Since certificate has been issued for my domain what is the way to download this

Probably a misunderstanding. Certificates are not stored centrally. They are generated directly on your system at runtime. If you delete them, they are gone.

If you have issues to create certificates, you would need to check the log why this failed.
If certificates are created successfully but still HTTPS is not working, web server log/config to be checked.

In general it’s better to move certificates into another folder to have them safely stored, before removing them completely.

thanks, i understand. The situation was created right at the time when dietpi needed to be updated and i forgot to renew the invalid certificate. Probably that is what messed up my system. My question may have not been clear: i have found those certificates in my system, but for some reason they were not automatically applied. In case this happens again, what is the way to apply the valid certificate that can anyway be found in my system and let certbot use it to apply?
Actually what i did now that in noip i have changed the domain name and run a certbot again. Now it works. Changing the domain was not an issue since i am the only one using it.

usually certificates are updated automatically by certbot.

If you need to change certificates manually, you can adjust https config located in /etc/lighttpd/conf-available

Thanks for the all input!

Please somebody elaborate how to make self signed ssl certificate, if i use this example what changes i have to make for making a selfsigned certificate for dietpi installed plex, adguard home & home assistant.

pnCert=/etc/lighttpd/ssl/pihole.example.com
fnCert=$pnCert/combined.pem

mkdir -p $pnCert
openssl req -new -x509 -newkey rsa:4096 -keyout $fnCert -out $fnCert -days 365 -nodes -subj "myDeets"
chown www-data:www-data $fnCert
chown www-data -R $pnCert
chmod 0600 $fnCert

systemctl restart lighttpd.service

i mostly understand all commands, only lighttpd portion is confusing as i donot know it is applicable to me or not.
I have two dietpi machines which resolved by unbound like nuc.local & rpi.local . i do not want to access system externally so not want to open port 80, 443 from router. i need only local lan access. my dietpi machines having following software installed
rpi.local >> homeassistant & bitwarden_RS (default ssl working)
nuc.local>> plex & adguard home.
I want same bitwarden rs type self signed certificate for plex, homeasssitant & adguard.
thanks

Plex, AdGuard Home as well as Home Assistant running there own web server. Therefore you don’t need to take care on any Lighttpd configration. You simply need to create the certificate. However I don’t see any benefit on having self signed certificate on a local network.

Do these instructions still apply?

I had an SD card crap out. While recreating this setup I am having new troubles. Diet-Pi v7.8.2, Raspberry Pi 4 Model B.

When I run lighty-enable-mod dietpi-https then restart lighttpd, lighttpd errors. The https redirect is enabled without error. external.conf and lighttpd.conf are modified, the cert is generated with correct permissions and ownership using the same script I posted earlier in this thread. lighttpd doesn’t error when dietpi-https is disabled, but obviously the webserver redirects to a page that can’t be served.

Here is the systemctl status.

● lighttpd.service - Lighttpd Daemon
     Loaded: loaded (/lib/systemd/system/lighttpd.service; disabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2021-12-06 15:02:52 EST; 6s ago
    Process: 49709 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=255/EXCEPTION)
        CPU: 447ms

Dec 06 15:02:52 diet systemd[1]: lighttpd.service: Scheduled restart job, restart counter is at 5.
Dec 06 15:02:52 diet systemd[1]: Stopped Lighttpd Daemon.
Dec 06 15:02:52 diet systemd[1]: lighttpd.service: Start request repeated too quickly.
Dec 06 15:02:52 diet systemd[1]: lighttpd.service: Failed with result 'exit-code'.
Dec 06 15:02:52 diet systemd[1]: Failed to start Lighttpd Daemon.

Edit: Note that I removed the ca-file lines in external.conf and 50-dietpi-https.conf because there is no CA for self-signed certs. I don’t think I mentioned that anywhere in this thread, but it is a helpful hint for people reading along.