Messages

1

German - Deutsch / Re: ACME Client mit DNS-01 challange seit letztem update bugged?

« on: October 07, 2024, 03:30:47 pm »

*Solved*
Also scheinbar hat sich tatsächlich irgendwo ein Fehlerteufel in ACME eingeschlichen.

Hat alles wunderbar geklappt nach dem in in den Einstellungen von ACME Client "Reset ACME Client" betätigt habe.

Stutzig macht mich das ganze trotzdem. Trotz dem speichern von neuen Tokens/Keys wurde die Änderung nicht angenommen.
Erst der Reset hat das bereinigt...

2

German - Deutsch / ACME Client mit DNS-01 challange seit letztem update bugged?

« on: October 07, 2024, 02:54:06 pm »

Hi @ll,

ich bin seit ein paar stunden am rödeln und überlegen was schief läuft. Ich hatte seit Jahren kein Problem mit meiner ACME config..

Seit gestern ist mein Zertifikat ausgelaufen und hätte heute erneuert werden sollen. Allerdings bekomme ich immer einen Fehler:

Code: [Select]

2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] _on_issue_err
2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] Error add txt for domain:_acme-challenge.mydomain.com
2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] invalid domain
2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] response='{"success":false,"errors":[{"code":9109,"message":"Invalid access token"}],"messages":[],"result":null}'
Wenn man das so liest denkt man "logisch, muss wohl der API Token futsch sein".
Hab um auf Nummer sicher zu gehen einen neuen Token erstellt.

Code: [Select]

Zone.Zone (Read), Zone.DNS (Edit) Ressources: All zonesDirekt in den challange types unter restricted API Token eingetragen

Gleicher Fehler...

Um mangelnde Rechte auszuschließen habe ich zum test meinen Global API Key getestet, aber da bekomme ich das gleiche Ergebnis.
Werdet ihr aus dem Log schlau? Diese Tokens im Log spiegeln nicht meine eingetragenen Token wieder.

Code: [Select]

2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] Error add txt for domain:_acme-challenge.mydomain.com
2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] invalid domain
2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] response='{"success":false,"errors":[{"code":9109,"message":"Invalid access token"}],"messages":[],"result":null}'
2024-10-07T14:25:41 acme.sh [Mon Oct 7 14:25:41 CEST 2024] ret='0'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _CURL='curl --silent --dump-header /var/etc/acme-client/home/http.header -L --trace-ascii /tmp/tmp.Qe7UxsMNNc -g '
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] Http already initialized.
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] timeout=
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] url='https://api.cloudflare.com/client/v4/zones/cf6666f77f5b50840cc4f8691d04a99c'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] GET
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] zones/cf6666f77f5b50840cc4f8691d04a99c
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] First detect the root zone
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] Adding txt value: iiOVah5YgiApm_W8j3cqevUJ8_bmE_MRfcG2wF3KmMLO for domain: _acme-challenge.mydomain.com
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] Found domain api file: /usr/local/share/examples/acme.sh/dnsapi/dns_cf.sh
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] dns_entry='mydomain.com,_acme-challenge.mydomain.com,,dns_cf,iiOVah5YgiApm_W8j3cqevUJ8_bmE_MRfcG2wF3KmMLO,/usr/local/share/examples/acme.sh/dnsapi/dns_cf.sh'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] d_api='/usr/local/share/examples/acme.sh/dnsapi/dns_cf.sh'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] txt='iiOVah5YgiApm_W8j3cqevUJ8_bmE_MRfcG2wF3KmMLO'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] txtdomain='_acme-challenge.mydomain.com'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _d_alias
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] d='mydomain.com'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] vlist='mydomain.com#rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48.Kg40Apx66il6cLWEg_W5cG5XoDgRmcWoSy11ohHmzt8#https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg#dns-01#dns_cf#https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/14315805543,'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] d
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] dvlist='mydomain.com#rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48.Kg40Apx66il6cLWEg_W5cG5XoDgRmcWoSy11ohHmzt8#https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg#dns-01#dns_cf#https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/14315805543'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] keyauthorization='rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48.Kg40Apx66il6cLWEg_W5cG5XoDgRmcWoSy11ohHmzt8'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] uri='https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] token='rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] entry='"type":"dns-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _authz_url='https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/14315805543'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] response='{"identifier":{"type":"dns","value":"mydomain.com"},"status":"pending","expires":"2024-10-14T12:25:39Z","challenges":[{"type":"tls-alpn-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/jkxsOA","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"http-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/-B_sZg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"dns-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"}]}#https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/14315805543'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _candidates='mydomain.com,{"identifier":{"type":"dns","value":"mydomain.com"},"status":"pending","expires":"2024-10-14T12:25:39Z","challenges":[{"type":"tls-alpn-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/jkxsOA","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"http-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/-B_sZg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"dns-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"}]}#https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/14315805543'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _idn_temp
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _is_idn_d='mydomain.com'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _currentRoot='dns_cf'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _w='dns_cf'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] Getting webroot for domain='mydomain.com'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] d='mydomain.com'
  '
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _authorizations_map='mydomain.com,{"identifier":{"type":"dns","value":"mydomain.com"},"status":"pending","expires":"2024-10-14T12:25:39Z","challenges":[{"type":"tls-alpn-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/jkxsOA","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"http-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/-B_sZg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"dns-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"}]}#https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/14315805543
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] _d='mydomain.com'
2024-10-07T14:25:40 acme.sh [Mon Oct 7 14:25:40 CEST 2024] response='{"identifier":{"type":"dns","value":"mydomain.com"},"status":"pending","expires":"2024-10-14T12:25:39Z","challenges":[{"type":"tls-alpn-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/jkxsOA","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"http-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/-B_sZg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"},{"type":"dns-01","url":"https://acme-staging-v02.api.letsencrypt.org/acme/chall-v3/14315805543/xpXTKg","status":"pending","token":"rstTYQYmrB3SCdyMSO_C2-KuKVWhfpP8w-UjWiA_L48"}]}'


3

German - Deutsch / Re: Wireguard - Trotz Handshake und connection kein traffic

« on: September 12, 2024, 03:34:02 pm »

Hi,
ich bin mir ziemlich sicher das die Key's identisch sind.
Ich bin unterwegs und wollte VPN als erstes ausprobieren (hatte in der vergangenheit auch geklappt).
Da ich nicht ohne VPN an meinen Server komme, kann ich die Konfiguration nicht einfach mal so neu erstellen.
Ich muss die Tage wenn ich wieder @home bin nochmal vergleichen. Allerdings hat das gestern @home im eigenen LAN auch funktioniert. Also connection war da und es ging... Darum bin ich auch so verwundert.
Ich dachte der Handshake an sich ist schon ein indiz das die schlüssel erfolgreich ausgetauscht wurden. Aber dann hab ich mich wohl geirrt. :/

4

German - Deutsch / Wireguard - Trotz Handshake und connection kein traffic

« on: September 12, 2024, 12:37:38 pm »

Hi @ll,

ich bin ein wenig irritiert was das VPN von meiner Linux Kiste betrifft.
Ich habe 2 Clients ( 1x Android, 1x Linux). Bei beiden habe ich die gleiche peer config um zu vergleichen.
Bei meinem Linux client handelt es sich um mein "admin-notebook".

Auf meinem Handy klappt die config ohne probleme. Ich komme überall hin und komme sogar auf mein OPNsense Dashboard + NAS..
Szenario: Ich deaktiviere das VPN auf meinem Handy und kurze Zeit darauf connecte ich mich über mein Notebook.

Die Verbindung würde laut Ausgabe und ifconfig stehen. Trotzdem kann ich leider weder pingen noch DNS auflösen. Habt ihr eine idee woran das liegen könnte?

Code: [Select]

# sudo wg show
interface: wg0
  public key: Ztq…xw=
  private key: (hidden)
  listening port: 57454
  fwmark: 0xca6c

peer: v3/pBIk…=
  preshared key: (hidden)
  endpoint: 95.x.x.x:51820
  allowed ips: 0.0.0.0/0
  latest handshake: 3 seconds ago
  transfer: 588 B received, 31.35 KiB sent

meine config:

Code: [Select]

[Interface]
PrivateKey = <redacted>
Address = 100.65.0.10/32
DNS = 100.65.0.1

[Peer]
PublicKey = v3/pB…=
PresharedKey = CE…=
AllowedIPs = 0.0.0.0/0
Endpoint = example.com:51820
Dadurch das mein Handy soweit keine probleme hat, gehe ich erstmal nicht von mangelnden rules aus. Zu Mal es ja die gleiche config ist. Es ist nur die gleiche config, weil ich testen wollte ob es bei einem anderen client auch nicht gehen würde.

5

General Discussion / Re: Webgui only accessible after a reset

« on: August 26, 2024, 02:17:22 pm »

Having a relarted similar issue 192.168.1.11 192.168.1.1 - [26/Aug/2024:08:10:41 -0400] "POST /api/diagnostics/log/core/lighttpd/clear HTTP/2.0" 200 15 "https://192.168.1.1/ui/diagnostics/log/core/lighttpd" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36"

If you dont use Adguard as a plugin, you have a different problem.
Mine was due to Adguard using the default http 80 port that usually opnsense was using. I had to change the config in an adguard config file via terminal.

6

Tutorials and FAQs / Re: Tutorial: Caddy (Reverse Proxy) + Let's Encrypt Certificates + Dynamic DNS

« on: August 23, 2024, 01:31:04 pm »

no one cares...
<delete me>

7

German - Deutsch / Re: WoL Plugin falscher Port? Wie richtig Magic Pakete versenden?

« on: July 06, 2024, 11:28:40 pm »

Hast recht. Funktioniert. Ich musste scheinbar neben WOL noch "Einschalten durch PCI/PCI-E" in einem anderen Bereich aktivieren. Jetzt gehts auch.
Jetzt müsste nur noch mein Broadcast Relay funktionieren.
Hast du auch ein Relay eingerichtet und kannst mir ein Beispiel geben, oder machst du alles nur über das WOL Plugin?

edit: Ich habe zur Vorsicht nochmal meine Subnetzmasken und deren Broadcast Adressen ausrechnen lassen *shame on me*
Mein WLAN wo mein PI sich befindet hat ein anderes subnetz als das vom zielsystem.
Allerdings reicht mein paket leider nicht rüber.
Ich habe mich gerade eben sogar vergewissert, dass eine FW regel im WLAN auch solche UDP pakete durch lässt.

8

German - Deutsch / WoL Plugin falscher Port? Wie richtig Magic Pakete versenden?

« on: July 06, 2024, 10:09:20 pm »

Hi @ll,

ich experimentier gerade ein bisschen und versuche einen Pi mit einem Wake on LAN Container zu betreiben um Host's in einem anderen Subnet / LAN zu wecken. Weitere infos dazu hier: https://github.com/sameerdhoot/wolweb
Allerdings gestaltet sich das ganze komplizierter als angenommen.

Ich habe versucht mein Zielhost mit dem OPNsense WOL Plugin zu wecken, allerdings klappt das nicht. Ich habe mich natürlich vergewissert, dass WOL im BIOS auf dem Zielsystem aktiviert ist.
Um zu überprüfen ob tatsächlich ein ein Paket an das System gesendet wird habe ich mal mit Wireshark nachgesehen.
Ein Paket wird verschickt. Allerdings nicht wie erwartet an Zielport UDP 7 oder 9, sondern an Port 40000?

Code: [Select]

User Datagram Protocol, Src Port: 14792, Dst Port: 40000
    Source Port: 14792
    Destination Port: 40000
    Length: 110
    Checksum: 0xfff2 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
    [Timestamps]
    UDP payload (102 bytes)

Alternativ habe ich versucht mit dem UDP Broadcast Relay das Paket weiter zu leiten, aber ich glaube mein Relay ist vielleicht falsch. Habt ihr eine Ahnung ob die config stimmt?

9

German - Deutsch / Re: Interner Proxy für VPN ohne public expose

« on: June 25, 2024, 09:34:26 am »

Sorry für den Spam hier, aber erst jetzt sehe ich diesen Error im Caddy.

Code: [Select]

"error","ts":"2024-06-25T06:53:33Z","logger":"http.log.access.37fc6c8b-42c2-41e0-baba-c38516660295","msg":"handled request","request":{"remote_ip":"100.65.0.10","remote_port":"47471","client_ip":"100.65.0.10","proto":"HTTP/1.1","method":"PROPFIND","host":"ncloud.example.com","uri":"/remote.php/dav/files/odin/","headers":{"Cookie":["REDACTED"],"Content-Length":["107"],"Content-Type":["text/xml; charset=UTF-8"],"Depth":["0"],"Authorization":["REDACTED"],"User-Agent":["Mozilla/5.0 (Android) Nextcloud-android/3.29.0"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"","server_name":"ncloud.example.com"}},"bytes_read":0,"user_id":"","duration":3.001101121,"size":0,"status":502,"resp_headers":{"Server":["Caddy"],"Alt-Svc":["h3=\":443\"; ma=2592000"]}}
"status":502,"resp_headers" = Bad Gateway

Ich denke damit kann ich erstmal arbeiten.

10

German - Deutsch / Re: Interner Proxy für VPN ohne public expose

« on: June 25, 2024, 07:33:05 am »

Vielen Dank nochmal für das Testen und die bisherige Hilfe.

Die Verschlüsselung kann vielleicht ein Grund sein für das Problem. Auf der anderen Seite wollte ich lediglich meine Weiche von außen nach innen verlegen, ohne großartig was umzustellen, bis auf eben die FW. Meine Nextcloud war im Grunde schon gut voreingestellt. Also ich musste wenig bis gar nichts konfigurieren. Es funktioniert ja an sich. Ich erhalte nur eben die Fehlermeldungen. Ich muss das ganze nochmal ein bisschen im Detail analysieren. Aber fraglich ob ich hier im Forum weitere Hilfe zu dem Thema erhalte, weil vermutlich sonst niemand so eine konfiguration auf die Beine gestellt hat.

Ich persönlich hasse Zertifikats Warnungen und "Ausnahmen". Es ist einfach ein nice to have, eine funktionierende Verschlüsselung innerhalb des eigenen Netzes zu haben. Gibt mir halt ein gutes Gefühl nach all den Jahren der Unsicherheit.

11

German - Deutsch / Re: Interner Proxy für VPN ohne public expose

« on: June 24, 2024, 05:01:55 pm »

Halte ich für Quatsch:

Code: [Select]

$ curl -v https://**********/.well-known/carddav
* Host **********:443 was resolved.
* [HTTP/2] [1] OPENED stream for https://**********/.well-known/carddav
< HTTP/2 301
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html
< date: Mon, 24 Jun 2024 10:17:49 GMT
< location: http://**********/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: nginx
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 162
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host ********** left intact


Ich hab's mir ja nicht aus dem Finger gesaugt. ^^ Wenn das offiziell so dokumentiert ist, gehe ich auch davon aus das die schon wissen warum sie das schreiben.

Mein Curl sieht ähnlich aus wie deiner. Keine Fehler. Und das ist auch das was mich stutzig macht. Den aufruf mache ich über den weg von innen. Wenn ich aber über den Browser navigiere sieht das wieder anders aus.

Code: [Select]

curl -v https://ncloud.example.com/.well-known/carddav
* Host ncloud.example.com:443 was resolved.
* IPv6: (none)
* IPv4: 192.168.1.1
*   Trying 192.168.1.1:443...
* Connected to ncloud.example.com (192.168.1.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=*.example.com
*  start date: Jun 21 13:40:44 2024 GMT
*  expire date: Sep 19 13:40:43 2024 GMT
*  subjectAltName: host "ncloud.example.com" matched cert's "*.example.com"
*  issuer: C=US; O=Let's Encrypt; CN=E5
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://ncloud.example.com/.well-known/carddav
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: ncloud.example.com]
* [HTTP/2] [1] [:path: /.well-known/carddav]
* [HTTP/2] [1] [user-agent: curl/8.8.0]
* [HTTP/2] [1] [accept: */*]
> GET /.well-known/carddav HTTP/2
> Host: ncloud.example.com
> User-Agent: curl/8.8.0
> Accept: */*
>
* Request completely sent off
< HTTP/2 301
< alt-svc: h3=":443"; ma=2592000
< content-type: text/html; charset=iso-8859-1
< date: Mon, 24 Jun 2024 11:08:10 GMT
< location: http://ncloud.example.com/remote.php/dav/
< referrer-policy: no-referrer
< server: Caddy
< server: Apache/2.4.59 (Debian)
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: noindex, nofollow
< x-xss-protection: 1; mode=block
< content-length: 335
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://ncloud.example.com/remote.php/dav/">here</a>.</p>
<hr>
<address>Apache/2.4.59 (Debian) Server at ncloud.example.com Port 80</address>
</body></html>
* Connection #0 to host ncloud.example.com left intact

Ich habe nochmal ein wenig verglichen und frage mich, ob das ein Fehler seitens Caddy, oder ein fehler meinerseits ist.

Wenn ich die Access Liste entferne, den HSTS Header über "header_down" nachreiche und wieder von außen auf Nextcloud zugreife, erhalte ich keine Warnmeldung.
Alle Header werden Ordnungsgemäß angezeigt. die .htaccess Warnmeldung verschwindet und ich habe keine Fehler mehr.

Nur wenn ich die Access Liste wieder rein nehme erhalte ich wieder massig Fehler und warnings über den Browser angezeigt.

12

German - Deutsch / Re: Interner Proxy für VPN ohne public expose

« on: June 24, 2024, 12:15:10 pm »

Steht hier in Service Discovery als erstes drin

https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies

13

German - Deutsch / Re: Interner Proxy für VPN ohne public expose

« on: June 24, 2024, 12:07:45 pm »

Da muss ich dir widersprechen.

The redirects for CalDAV or CardDAV does not work if Nextcloud is running behind a reverse proxy. The recommended solution is that your reverse proxy does the redirects.

Das gleiche hatte ich bei mir im NGINX auch drin gehabt.

14

German - Deutsch / Re: Interner Proxy für VPN ohne public expose

« on: June 24, 2024, 12:03:34 pm »

Das + scheint hier leider auch nicht zu helfen. Ich habe mir die Doku vorher auch mal angesehen. Ich bin auch unsicher, ob man vielleicht Header "ersetzen" bzw. mit seinem Header überschreiben muss.

header_down sets, adds (with the + prefix), deletes (with the - prefix), or performs a replacement (by using two arguments, a search and replacement) in a response header coming downstream from the backend.

Code: [Select]

handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up +Referrer-Policy "no-referrer"
header_up +Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
header_up +X-Content-Type-Options "nosniff"
header_up +X-Frame-Options "SAMEORIGIN"
header_up +X-Permitted-Cross-Domain-Policies "none"
header_up +X-Robots-Tag "noindex, nofollow"
header_up +X-XSS-Protection "1; mode=block"

fail_duration 30s
}

Proxy config

Code: [Select]

  'trusted_proxies' =>
  array (
    0 => '192.168.200.1', #Opnsense Interface für Unraid
  ),

Was ich leider bei Caddy in der GUI nicht finde, sind so Weiterleitungen wie diese hier aus der Nextcloud Doku:

Code: [Select]

   
    redir /.well-known/carddav /remote.php/dav/ 301
    redir /.well-known/caldav /remote.php/dav/ 301

Dafür das Caddy so einfach ist, ist es doch schon ganz schön kompliziert.

Interessant finde ich auch diese Meldung. Sowas hatte ich vorher mit NGINX nicht.

Code: [Select]

Dein Datenverzeichnis und deine Dateien sind wahrscheinlich vom Internet aus erreichbar. Die .htaccess-Datei funktioniert nicht. Es wird dringend empfohlen, deinen Webserver dahingehend zu konfigurieren, dass das Datenverzeichnis nicht mehr vom Internet aus erreichbar ist oder dass du es aus dem Document-Root-Verzeichnis des Webservers herausverschiebst.

15

German - Deutsch / Re: Interner Proxy für VPN ohne public expose

« on: June 24, 2024, 09:52:22 am »

Ich bin wiedermal ratlos.

Die Syntax schient wohl nix auszumachen, weil es eh nicht am Server ankommt. Ich bekomme aber noch mehr Fehler/Warnmeldeungen als vorher angezeigt.
Die Header in NGINX zu erstellen und zu nutzen war einfacher als das hier.

Was ich in der Einrichtungswarnung bei Nextcloud erhalte:

Code: [Select]

Einige Header sind in deiner Instanz nicht richtig eingestellt - Der HTTP-Header `X-Content-Type-Options` ist nicht auf `nosniff` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Robots-Tag` ist nicht auf `noindex,nofollow` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Frame-Options` ist nicht auf `sameorigin` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-Permitted-Cross-Domain-Policies` ist nicht auf `none` gesetzt. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `X-XSS-Protection` enthält nicht `1; mode=block`. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar und es wird empfohlen, diese Einstellung zu ändern. - Der HTTP-Header `Referrer-Policy` ist nicht auf "no-referrer", "no-referrer-when-downgrade", "strict-origin", "strict-origin-when-cross-origin" oder "same-origin" gesetzt. Dadurch können Verweisinformationen preisgegeben werden. Siehe die W3C Recommendation. - Der `Strict-Transport-Security`-HTTP-Header ist nicht gesetzt (er sollte mindestens `15552000` Sekunden betragen). Für erhöhte Sicherheit wird empfohlen, HSTS zu aktivieren. Weitere Informationen findest du in der Dokumentation ↗.
Was ich eingestellt habe:

Code: [Select]

handle @0ca7ce31-a10f-46f1-90a0-b8a87f40a05f {
handle {
reverse_proxy 192.168.200.2:8666 {
header_up Referrer-Policy "no-referrer"
header_up Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
header_up X-Content-Type-Options "nosniff"
header_up X-Frame-Options "SAMEORIGIN"
header_up X-Permitted-Cross-Domain-Policies "none"
header_up X-Robots-Tag "noindex, nofollow"
header_up X-XSS-Protection "1; mode=block"

fail_duration 30s
}
}
}
Auf dem Server in den Logs finde ich z.B. sowas:

Code: [Select]

"reqId":"VUfbD1ANpY87CywcjSff","level":0,"time":"2024-06-24T07:38:13+00:00","remoteAddr":"172.17.0.1","user":"--","app":"webdav","method":"GET","url":"/remote.php/dav/",
"message":"No public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorizatio
n: Bearer' header found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or
 the server is misconfigured","userAgent":"Nextcloud Server Crawler","version":"29.0.2.2","exception":{"Exception":"Sabre\\DAV\\Exception\\NotAuthenticated","Message":"No
 public access to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' he
ader found. Either the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server i
s misconfigured","Code":0,"Trace":[{"file":"/var/www/html/3rdparty/sabre/event/lib/WildcardEmitterTrait.php","line":89,"function":"beforeMethod","class":"Sabre\\DAV\\Auth
\\Plugin","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":456,"function":"em
it","class":"Sabre\\DAV\\Server","type":"->","args":["beforeMethod:GET",[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]]},{"file":"/var/www/html/3rdparty/sabre/dav/l
ib/DAV/Server.php","line":253,"function":"invokeMethod","class":"Sabre\\DAV\\Server","type":"->","args":[["Sabre\\HTTP\\Request"],["Sabre\\HTTP\\Response"]]},{"file":"/va
r/www/html/3rdparty/sabre/dav/lib/DAV/Server.php","line":321,"function":"start","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/lib/Se
rver.php","line":374,"function":"exec","class":"Sabre\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/apps/dav/appinfo/v2/remote.php","line":35,"function":"ex
ec","class":"OCA\\DAV\\Server","type":"->","args":[]},{"file":"/var/www/html/remote.php","line":172,"args":["/var/www/html/apps/dav/appinfo/v2/remote.php"],"function":"re
quire_once"}],"File":"/var/www/html/3rdparty/sabre/dav/lib/DAV/Auth/Plugin.php","Line":152,"message":"No public access to this resource., No 'Authorization: Basic' header
 found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Either the client didn't send one, or the server is mi
s-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured","exception":{},"CustomMessage":"No public access
to this resource., No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured, No 'Authorization: Bearer' header found. Eit
her the client didn't send one, or the server is mis-configured, No 'Authorization: Basic' header found. Either the client didn't send one, or the server is misconfigured
"}}