Eigentlich sagt die Überschrift schon alles. Safari verweigert gerade (insgesamt schon zum zweiten Mal binnen ca. acht Tagen), Mactechnews.de anzuzeigen. Ich muss dann eine händische Freigabe der Seite initiieren, um die Seite angezeigt zu bekommen.
Ist das ein Fehler des Zertifikats von Mactechnews oder muss ich selbst irgendwas an den Einstellungen verändern?
Nachdem die Seite angezeigt wird, wird sie von Safari als "Nicht sicher" gemeldet.

Also unter macOS 12.6.1 und Safari 16.1 wird alles korrekt angezeigt. Zertifikat läuft bis 13.11.2023

Das passiert bei Sites, die man noch mit "http://"-Präfix aufruft (weil damit die SSL-Verschlüsselung nicht genutzt wird). Du solltest die URL des Lesezeichens auf "https://…" umstellen.

MacTechNews läuft hier problemlos in Ventura.

Das Zertifikat sollte stimmen – ich kann nix auffälliges entdecken.

KJM
Hier zeigt Safari http-seinen zwar mit "NICHT SICHER" in der Adressleiste an, aber ohne große Warnung. Wenn ich manuell "http://www.mactechnews.de" eingebe, kommt auch keine Warnung und es findet ein von uns initiierter redirect auf https://.... statt.

Meine Adresse war auf https://www.mactechnews ... eingestellt. Noch merkwürdiger: das Problem erschien nach einem einfachen Reload der Seite. Und das, wie gesagt, schon zum zweiten Mal binnen Kurzem. Trotz https:... wird mir die Seite jetzt weiterhin als "Nicht sicher" angezeigt.
Ich verstehe es nicht.

Rosember
Kannst du mal die Meldung posten, die genau erscheint UND was erscheint, wenn du auf das Schloss drauf drückst?

Ist irgendwas außergewöhnliches in deinem Netzwerk aktiv? Eine besondere Firewall?

Leider habe ich die Meldung nicht abgespeichert. Es war jedoch genau diejenige, die Safari einblendet, wenn man eine unsichere Seite erstmals ansurft: Die Seite ist weiß, ein Text weißt darauf. hin, dass man eine unsichere Seite angewählt hat und deshalb das Laden verweigert wurde. In dem Katen um diesen Text kann man dann auch noch Details zu der Webseite anzeigen lassen – und dort gegebenenfalls das Anzeigen „erzwingen“. – Ich weiß nicht, ob dir die Beschreibung hilft. Es ist wirklich eine Standardmeldung unter Safari.
Erstaunlich ist, dass ich am iPad, von dem ich gerade schreibe, die Seite als „sicher“ (mit Schloss) angezeigt bekomme, also alles so funktioniert wie immer. Ich bin sowohl am Mac, als auch am iPad pro (iPadOS 16.1) mit der gleichen Id angemeldet - und dennoch unterscheidet sich die Anzeige in der Adresszeile von Safari …
Mein Netzwerk ist nur insofern (leider) besonders, als ich an meinem Wohnort auf einen Internetzugang per Mobilnetz (Gigacube mit Flatrate) angewiesen bin. Hinter dem Gigacube folgt dann eine Fritzbox, die den Zugang per WLAN und Ethernet im Haus verteilt. Das ist alles.

Rosember
Das ist wirklich sehr, sehr merkwürdig – besonders der Fakt, dass es oftmals bei dir auf dem Mac normal funktioniert.

Das komische ist: Wenn du eine Webseite anrufst, die NUR http und kein https kann (z.B. ), erscheint ja in Safari diese Meldung, die du beschreibst, nicht. Diese kommt meines Wissens nach nur, wenn du eine Webseite kontaktierst, deren Zertifikat oder die Zertifikatkette vorhanden aber invalide ist. Wenn ich diese Meldung noch richtig im Kopf habe, wird dir dort ja angezeigt, was bzw. welches Zertifikat Safari zu der Meldung veranlasst hat. Wenn das Problem wieder auftritt: Kannst du das mal screenshotten und hier einstellen?

Rosember
Hast du irgendwelche "Erweiterungen" installiert?
Lässt sich das Problem reproduzieren indem du den Verlauf von Safari löscht?

Virenscanner oder andere Sicherheitssoftware installiert?

Mendel Kucharzek
Mache ich, klar!
Übrigens, Korrektur, funktioniert die Seite am Mac "nicht richtig", auf dem iPad hingegen wird sie ganz normal als sichere Seite angezeigt.

Erweiterungen habe ich keine installiert außer einem gängigen Werbeblocker (AdBlock). Den Verlauf von heute habe ich gelöscht: alles bleibt unverändert. Und auch sonst ist der Rechner unbefleckt von irgendwelchen "Versuchen", weil er mein Arbeitsrechner ist.

Werbeblocker nicht nur deaktivieren sondern komplett löschen und erneut testen. Safari Cache löschen und von vorne beginnen. Auch mal sämtliche Netzwerkkomponenten neu starten, damit diese definitiv alles aktualisieren und der interne Speicher leer ist.

Nach einem Neustart des Rechners ohne sonstige Maßnahmen wird die Seite auch am Mac wieder als sicher angezeigt ...

Ich habe das Problem auch temporär. z.B. mit welt.de (der Zeitung)
Allerdings habe ich auch Adblock und DuckDuckGo installiert. In der Regel ist der Fehler nach Neustart oder löschen des Cache weg. Oder ich wechsle auf Chrome wenn ich nicht gerade neu starten kann.

PS: Da fällt mir auf: Das Problem tritt nur auf, wenn ich auf einer Seite automatisch als User / LogIn eingetragen bin. Also "automatisch anmelden".

Aktualisierung: Heute morgen hatte ich wieder die gleichen Zertifikat-Probleme, diesmal unter Ventura 13.1 und Safari 16.2. Die angezeigte Meldung sah so aus:
Ich hoffe, das hilft irgendwie weiter ...

Ich habe mir das gerade mal angesehen. Die Fehlermeldung behauptet ja, die Webseite unterstütze nur TLS 1.0 und 1.1, das stimmt schon mal definitiv nicht:


Daß TLS 1.3 nicht angeboten wird ist (noch) OK.

Allein das weist schon darauf hin, daß zwischen Deinem Safari und mactechnews irgendwer an der SSL-Verbindung herumspielt.

Ich weiß aus einem anderen Kontext, daß der Vodafone Gigacube netzwerktechnisch problematisch ist (zum Beispiel demoliert er DNS-Pakete), das wäre also ein möglicher Kandidat. Theoretisch könnten es auch "Optimierungen" seitens Vodafone sein, die zu einem Downgrade der TLS-Verbindung führen.

Kannst Du bitte mal folgendes im Terminal eingeben:
(keine Angst, es explodiert nichts) und das Ergebnis hier posten?

Das OpenSSL (bzw. LibreSSL), das macOS mitliefert, ist zwar vollkommen veraltet aber dafür reicht es noch. Anhand der Ausgabe können wir zumindest sehen, ob Dein Client netzwerkseitig wirklich mit MTN redet oder ob da etwas dazwischen ist.

So ganz perfekt ist die TLS-Seite bei MTN übrigens auch nicht konfiguriert:

Die Eingabe des Terminalbefehls ergibt das Folgende:
xxxxxxxx@MacBook-Pro-M1 ~ % openssl s_client -connect mactechnews.de:443 CONNECTED(00000005) depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA verify return:1 depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2 verify return:1 depth=0 CN = *.mactechnews.de verify return:1 write W BLOCK --- Certificate chain 0 s:/CN=*.mactechnews.de i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIHRDCC ... vt2vf3eLH8g== -----END CERTIFICATE----- subject=/CN=*.mactechnews.de issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 --- No client certificate CA names sent Server Temp Key: ECDH, P-384, 384 bits --- SSL handshake has read 3744 bytes and written 445 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 4096 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: E40A000047907BC6B420F2922163F5CEB850333BCF92BC5D3C8234F0A77C9739 Session-ID-ctx: Master-Key: 9A7A4273622E111B89F5CE3A17219243EBE234E9A678A90FC2CDE1D65645D1C9D77A9B6B307D095C1AC53DA11A7C367B Start Time: 1671535349 Timeout : 7200 (sec) Verify return code: 0 (ok) ---

OK, die wichtigen Teile:
1. Das Zertifikat ist korrekt und Du redest mit dem richtigen Server (gut)
2. TLS 1.2 wird unterstützt (auch gut)

Das sagt uns immerhin schon mal, daß Dein Rechner und Dein Netzwerk prinzipiell kein Problem haben, MTN direkt zu erreichen.

Kannst Du, wenn Safari mal wieder MTN als "nicht sicher" einstuft, auch mal das Zertifikat anzeigen lassen, das Safari nicht gefällt? Das geht, wenn Du nach dem Klick auf "diese Seite besuchen" in der Fehlermeldung das Schloß in der URL-Zeile anklickst.

Mache ich!
Aktuell zeigt Safari das Zertifikat wieder als "sicher" an - was mich wundert, denn vorhin hieß es noch die Verbindung sei unsicher. Bei irgendeinem Ladevorgang muss das umgesprungen sein - ?