https met trusted certificaat lokaal werkend krijgen

[thomke]

Mijn vraag:
Ik heb een grafana server draaien op linux (ubuntu).
Ik zou deze grafana server willen bereiken van uit een client die op het lokaal netwerk draait (dus niet via publiek domein). Dit moet HTTPS en zonder waarschuwing dat het ssl certificaat 'untrusted' is.

Relevante software en hardware die ik gebruik:
De grafana server draait op een linux ubuntu systeem (niet in docker)
De grafana server moet zal toegankelijk moeten zijn vanuit een 'iframe' van een andere web applicatie
(siemens WINCC Unified) maar deze informatie is minder relevant.
De voorwaarde voor de 'iframe' is wel dat de site die er in opgeroepen wordt 'HTTPS' is (en dus ook zonder de 'untrusted certificate' waarschuwingen)

Wat ik al gevonden of geprobeerd heb:
Mijn eerste stap is gewoon vanuit een windows binnen ditzelfde netwerk te kunnen de grafana te openen (via ip adres van de linux) via https en zonder de 'untrusted' waarschuwing.

Het eerste deel is reeds gelukt 'https' werkend krijgen:
Dit heb ik via deze informatie gedaan:
https://grafana.com/docs/...tup-grafana/set-up-https/

Vervolgens heb ik het geprobeerd om weer zelf certificaten aan te maken via deze manier:
https://deliciousbrains.c...-local-https-development/

Dus door zelf een 'Certificate Authority' te zijn en deze toe te voegen aan de 'Trusted Root Certification Authorities' in windows zoald uitgelgd in de link.
en deze nieuwe .key en .crt te gebruiken voor grafana..

maar ik krijg dus nog steeds de waarschuwing dat deze 'untrusted' zijn.


Ik ken hier bitter weinig van. Ik snap hoe https en de certificaten werken. Ik snap ook wat ik doe door die 'tutorials' te volgen. Maar ik snap dus niet waarom het niet werkt.
misschien kan er iemand verwijzen naar een bete stappenplan om dit werkend te krijgen.
Of die die een idee heeft waar het mis zou kunnen gaan..

Groeten,
Thomas

[ Voor 2% gewijzigd door thomke op 04-01-2024 13:14 . Reden: typo ]

[eheijnen]

Kijks een of je hier iets aan hebt. Gratis en volledig functionele SSL certificaten.
https://letsencrypt.org/

[Janoz]

Voor de oplossing van @eheijnen heb je wel een domeinnaam nodig. Als je zelf geen domein hebt dan kun je met letsencrypt ook weinig omdat er niks is om daadwerkelijk je certificaat voor aan te vragen.

[thomke]

eheijnen schreef op donderdag 4 januari 2024 @ 13:01:
Kijks een of je hier iets aan hebt. Gratis en volledig functionele SSL certificaten.
https://letsencrypt.org/

Ik gebruik geen domein naam, dit is een compleet 'offline' lokaal netwerk. Dus dan lukt 'letsencrypt' (deze doet een validatie van uw domeinnaam als ik het goed heb)

[thomke]

Janoz schreef op donderdag 4 januari 2024 @ 13:04:
Voor de oplossing van @eheijnen heb je wel een domeinnaam nodig. Als je zelf geen domein hebt dan kun je met letsencrypt ook weinig omdat er niks is om daadwerkelijk je certificaat voor aan te vragen.

Inderdaad, dat is ook hoe ik het verstond en daarom geen gebruik gemaakt heb van 'letsencrypt'

[Janoz]

Dat alles lokaal draait betekent trouwens niet dat je dus geen domein kunt gebruiken. Ik heb zelf op mijn netwerk heel veel lokale diensten draaien, maar hiervoor gebruik ik wel mijn eigen domein. In mijn lokale DNS server heb ik opgenomen dat alles dat naar *.mijndomein.tld gaat wordt doorgestuurd naar mijn lokale server. In dat geval kan ik wel de door letsencrypt aangemaakte certificaten gebruiken.

[Paul]

Zonder domein is het makkelijkste is een self-signed certificate te maken en (de public key van) dat certificaat op de PC met de browser in de trust store te zetten (bijvoorbeeld https://support.kaspersky...race/3.1/en-US/174127.htm voor Windows; voor andere operating systems (en voor Firefox) moet je even zoeken hoe je een self signed certificate kunt trusten).

Een ingewikkelder manier is het optuigen van een eigen interne CA. Die moet je ook handmatig op alle clients toevoegen, maar dan kun je andere servers of services ook van certificaat voorzien zonder dat je steeds alle clients af moet.

[eheijnen]

Janoz schreef op donderdag 4 januari 2024 @ 13:04:
Voor de oplossing van @eheijnen heb je wel een domeinnaam nodig. Als je zelf geen domein hebt dan kun je met letsencrypt ook weinig omdat er niks is om daadwerkelijk je certificaat voor aan te vragen.

Dacht...misschien heeft ie een domeinnaam...

[Hero of Time]

Zelfs al heb je alles in plaats voor een complete trusted chain voor certificaten en domeinen. Als je de server op IP adres gaat benaderen, krijg je hoe dan ook een melding over untrusted. Want het IP adres staat niet in het SAN van het certificaat, die heb je niet meegegeven bij het aanvragen. Publieke CAs zoals o.a. Lets Encrypt zullen dat niet zomaar toepassen op het uitgegeven certificaat.

Met een eigen interne CA kan je dat wel doen. Zorg dus dat je bij het ceritificate request je extra Subject Alternate Names meegeeft met IP:<ipadres>. Dan hoef je alleen het publieke certificaat van je CA te importeren op je systemen om geen melding te krijgen.

Houd er ook rekening mee dat Firefox mogelijk nog naar z'n eigen certificate store kijkt. Het gedrag is onlangs in de normale releases verandert of gebeurt binnenkort, maar bij ESR en op Linux kan dat nog anders zijn. Merk je snel genoeg, maar houd dit even in het achterhoofd.


Overigens is dit niet zozeer een Linux vraag, maar een Server Software vraag en verplaats het topic dan ook naar het juiste forum. LNX -> SSC.

[proatjeboksem]

thomke schreef op donderdag 4 januari 2024 @ 12:10:

maar ik krijg dus nog steeds de waarschuwing dat deze 'untrusted' zijn.

Wat is de precieze melding dan? Want ik vermoed dat de certificaten van je Root CA, die van je eigen "Certificate Authority" nog niet overal geland zijn. Of je browser op je client pc vertrouwt je eigen certificaat-keten toch niet zo.

een mooie truuk om alle certificaten te controleren die in een https request meekomen, is openssl
openssl s_client -showcerts -servername www.example.com -connect www.example.com:443 </dev/null

dat kan op je linux bak, maar ook op je windows machine, alleen moet je dan die stdin redirect < /dev/null ff vervangen door een pipe: echo "Q" | <en dan de openssl opdracht>

[ Voor 8% gewijzigd door proatjeboksem op 09-01-2024 12:11 ]