Problemen met SSL certificaat voor IIS binnen een Intranet

[aad.slingerland]

Beste *.*
Ik probeer een SSL certificaat voor elkaar te krijgen voor IIS 10 op een Winows 2019 server in combinatie met een eigen Active Directory Certificate Service, ook op een Windows 2019 server. En dat komt maar niet goed want browsers (Chrome, Firefox) blijven piepen dat de site niet veilig is

(NET::ERR_CERT_COMMON_NAME_INVALID)

Bij de certificaat aanvraag (binnen IIS beheer) heb ik de common name diverse malen dubbel en dwars gecontrolleerd. De verwerking van de certificaat aanvraag (CSR) gaat binnen ADCS ook goed en het weer importeren van het resultaat van ACDS binnen IIS ook weer) . En ik ben niet vergeten de Binding voor de default website aan te passsen.

Het enige dit iik nu zelf nog kan bedenken dat er mogelijk een conflict is tussen de gebruikte FQDN voor deze organisatie en wat door IIS/Microsoft als "correct" word gezien.

De FQDN voor deze Active Directory is:

liemerskunstwerk.intra

.INTRA omdat het over een INTRAnet gaat en ik geen conflict wilde creeren met liemerskuntwerk.nl (die ook bestaat).

Wellicht dat iemand iets kan roepen over deze situatie....

Goet, Aad Slingerland

Mijn servers (drie stuks) zijn HP met WIndows 2019. Active Directory voor gebruikers,. security groups, computers, GPO's. De organisatie waar ik voor bezig ben (als vrijwilliger) is het Liemers Museum, onderdeel van LiemersKunstwerk.

[ Voor 3% gewijzigd door aad.slingerland op 04-03-2024 18:37 ]

[Urk]

Met de ervaring die ik hiermee heb zou dit wel eens kunnen liggen aan de instellingen van de template van de betreffende certificaat aanvraag binnen Active Directory Certificate Service. Die kan overschrijven wat jij in het cert request opvoert volgens mij...

[Nakebod]

Heb je op de clients wel je Root CA geïmporteerd?
Zolang dat niet is zal je altijd een certificate error houden.

[aad.slingerland]

Nakebod schreef op maandag 4 maart 2024 @ 18:42:
Heb je op de clients wel je Root CA geïmporteerd?
Zolang dat niet is zal je altijd een certificate error houden.

Jawel, de root CA is gedistribueert naar alle clients Thanks

[aad.slingerland]

Urk schreef op maandag 4 maart 2024 @ 18:42:
Met de ervaring die ik hiermee heb zou dit wel eens kunnen liggen aan de instellingen van de template van de betreffende certificaat aanvraag binnen Active Directory Certificate Service. Die kan overschrijven wat jij in het cert request opvoert volgens mij...

Roger, daar zal ik eens op inzoomen. Thanks

[pennywiser]

Dat .intra en ook .lan en .local wordt dat nog geaccepteerd binnen CA's? Misschien lukt het aanvragen van een certificaat wel, maar is dit voor de moderne browsers een probleem.

[SambalBij]

De melding die je krijgt ((NET::ERR_CERT_COMMON_NAME_INVALID)) duidt er op dat op de common name van je certificaat een andere hostname staat dan degene die je browser probeert op te halen.

Je kunt twee dingen eens nakijken; welke CN geeft de browser aan die hij op het certificaat ziet? En welke hostname staat er in de adresbalk van je browser? Klik de foutmelding eens door en bekijk via de browser het certificaat.

(Als er ergens binnen die intranetsite een forward of rewrite wordt gedaan naar een andere hostname, dan kan het zijn dat ie ook gaat zeuren om het certificaat - Als voorbeeld; jij hebt een certificaat gegenereerd voor intranet.liemerskunstwerk.intra (waar je ook heen gaat) maar de website zelf forward je vervolgens naar een server naam of iets als web-01.liemerskunstwerk.infra, dan zou je ook die melding krijgen)

[pennywiser]

SambalBij schreef op maandag 4 maart 2024 @ 19:22:
De melding die je krijgt ((NET::ERR_CERT_COMMON_NAME_INVALID)) duidt er op dat op de common name van je certificaat een andere hostname staat dan degene die je browser probeert op te halen.

Je kunt twee dingen eens nakijken; welke CN geeft de browser aan die hij op het certificaat ziet? En welke hostname staat er in de adresbalk van je browser? Klik de foutmelding eens door en bekijk via de browser het certificaat.

(Als er ergens binnen die intranetsite een forward of rewrite wordt gedaan naar een andere hostname, dan kan het zijn dat ie ook gaat zeuren om het certificaat - Als voorbeeld; jij hebt een certificaat gegenereerd voor intranet.liemerskunstwerk.intra (waar je ook heen gaat) maar de website zelf forward je vervolgens naar een server naam of iets als web-01.liemerskunstwerk.infra, dan zou je ook die melding krijgen)

Maar zo'n .intra wordt toch door geen enkele browser geaccepteerd in 2024 ook al kloppen de hostnames? Dus of zelf CA in je browser zetten, of over naar een tld welke wel op internet geaccepteerd wordt.

Daarom zijn veel bedrijven die ik ken overstapt van bedrijfsnaam.intra naar bedrijfsnaaminternal.com of intra.bedrijfsnaam.com.

[Urk]

aad.slingerland schreef op maandag 4 maart 2024 @ 19:13:
[...]


Roger, daar zal ik eens op inzoomen. Thanks

Graag gedaan. Ja kijk eens goed welke CN er in het certificaat wordt genoemd die door AD CS is uitgegeven.
En kijk ook even of je browser (bij Firefox is dat bijv. een niet standaard instelling) wel de Root certificate store van Windows ook gebruikt.

[ Voor 20% gewijzigd door Urk op 04-03-2024 19:36 ]

[aad.slingerland]

pennywiser schreef op maandag 4 maart 2024 @ 19:16:
Dat .intra en ook .lan en .local wordt dat nog geaccepteerd binnen CA's? Misschien lukt het aanvragen van een certificaat wel, maar is dit voor de moderne browsers een probleem.

Daar begint het inderdaad op te lijken. Kijk ook maar eens hier: https://news.ycombinator.com/item?id=39152306

Ik ben aan het spitten of ik Chrome (dat is de enige browser die hier nu gebruikt word) zo gedresseerd kan worden dat die .intra wel accepteerd. My god wat heb ik mijn hals gehaald

[pennywiser]

aad.slingerland schreef op maandag 4 maart 2024 @ 20:06:
[...]


Daar begint het inderdaad op te lijken. Kijk ook maar eens hier: https://news.ycombinator.com/item?id=39152306

Ik ben aan het spitten of ik Chrome (dat is denige browser die hier nu gebruikt word) zo gedresseerd kan worden dat die .intra wel accepteerd. My god wat heb ik mijn hals gehaald

Na, je moet radicaal van dat .intra af. Dat moet toch. Vraag een certificaat met een normale tld aan zoals .nl of .com en creëer een subdomein zoals intra.bedrijfsnaam.nl. Dat subdomein moet je wel in IIS ook aanmaken denk ik eerst. In Apache gaat dat dmv een vhost, in IIS weet ik dat niet.

Als je meteen een wildcard aanvraagt op het hoofddomein kan je die ook voor het subdomein gebruiken en heb je maar 1 certificaat nodig.

Vraag deze dan aan voor:

bedrijfsnaam.nl (zonder subdomein) en
*.bedrijfsnaam.nl (ster)

Dat scheelt je certificaat kosten.

[Hero of Time]

Wij hebben op de zaak helaas nog een .local domein en een interne CA. Certificaten die we hieruit krijgen werken bij ons prima.

Geen idee wat er met .intra wordt gedaan, dat kan mogelijk een issue zijn. Maar gezien de melding denk ik dat wat hierboven al is aangegeven het probleem is. De common name is niet goed. Het is mogelijk dat deze melding ook wordt getoond als alleen de CN is opgegeven en er geen Subject Alt Name is ingevuld. Zie ook https://security.stackexc...-other-browsers-ie-follow, een post van >6 jaar oud!

[pennywiser]

Hero of Time schreef op maandag 4 maart 2024 @ 20:16:
Wij hebben op de zaak helaas nog een .local domein en een interne CA. Certificaten die we hieruit krijgen werken bij ons prima.

Geen idee wat er met .intra wordt gedaan, dat kan mogelijk een issue zijn. Maar gezien de melding denk ik dat wat hierboven al is aangegeven het probleem is. De common name is niet goed. Het is mogelijk dat deze melding ook wordt getoond als alleen de CN is opgegeven en er geen Subject Alt Name is ingevuld. Zie ook https://security.stackexc...-other-browsers-ie-follow, een post van >6 jaar oud!

Er moet ook een lokale root CA in jullie browser gezet zijn anders komt er toch echt een cn invalid error. Het is namelijk een self signed, je zegt het zelf, interne CA.

[Hero of Time]

pennywiser schreef op maandag 4 maart 2024 @ 20:20:
[...]

Er moet ook een lokale root CA in jullie browser gezet zijn anders komt er toch echt een cn invalid error. Het is namelijk een self signed, je zegt het zelf, interne CA.

Wanneer er gebruik gemaakt wordt van ADCS zal het root CA daarvan automatisch via AD naar de clients gepusht worden. Daar hoef je niks voor te doen. En alleen Firefox heeft mogelijk nog wat overtuiging nodig om de certificate store van het OS te gebruiken. Chrome kijkt al naar die van het OS.

[pennywiser]

Hero of Time schreef op maandag 4 maart 2024 @ 20:24:
[...]

Wanneer er gebruik gemaakt wordt van ADCS zal het root CA daarvan automatisch via AD naar de clients gepusht worden. Daar hoef je niks voor te doen. En alleen Firefox heeft mogelijk nog wat overtuiging nodig om de certificate store van het OS te gebruiken. Chrome kijkt al naar die van het OS.

Nee ok, ADCS, maar dat is hetzelfde als wat ik bedoel: self signed.

[Jazzy]

Bekijk het certificaat dan eens via de browser. De naam die je in de adresbalk van je browser typt moet op het certificaat staan bij Onderwerp en dan nogmaals bij Alternatieve naam voor entiteit van certificaat. Of de Engelstalige equivalenten van die termen.

[pennywiser]

Jazzy schreef op maandag 4 maart 2024 @ 20:32:
Bekijk het certificaat dan eens via de browser. De naam die je in de adresbalk van je browser typt moet op het certificaat staan bij Onderwerp en dan nogmaals bij Alternatieve naam voor entiteit van certificaat. Of de Engelstalige equivalenten van die termen.

Het probleem is (denk ik) de tld .intra waar browsers tegenwoordig op faulten.

[aad.slingerland]

pennywiser schreef op maandag 4 maart 2024 @ 20:13:
[...]

Na, je moet radicaal van dat .intra af. Dat moet toch. Vraag een certificaat met een normale tld aan zoals .nl of .com en creëer een subdomein zoals intra.bedrijfsnaam.nl. Dat subdomein moet je wel in IIS ook aanmaken denk ik eerst. In Apache gaat dat dmv een vhost, in IIS weet ik dat niet.

Als je meteen een wildcard aanvraagt op het hoofddomein kan je die ook voor het subdomein gebruiken en heb je maar 1 certificaat nodig.

Vraag deze dan aan voor:

bedrijfsnaam.nl (zonder subdomein) en
*.bedrijfsnaam.nl (ster)

Dat scheelt je certificaat kosten.

Ik begrijp je redenering helemaal. Maar de consequenties zijjn nogal heftig als ik dit consequent wil gaan doorvoeren.

Als ik liemerskunstwerk.intra consequent ga vervangen voor (bijvoorbeeld) intra.liemerskunstwerk.nl dan kan ik van vooraf aan beginnen met het inrichten van Active Directory. Over een klusje gesproken

Het is wel een punt dat ik met mij twee collega ICT'ers op ga nemen, en met de hogere legerleiding...

Wordt vervolgd. Thanks!

[Jazzy]

pennywiser schreef op maandag 4 maart 2024 @ 20:34:
[...]

Het probleem is (denk ik) de tld .intra waar browsers tegenwoordig op faulten.

Was ik me niet van bewust. Heb je een linkje waar ik hier meer over kan lezen? Ik weet alleen dat publieke certificate authorities er geen certificaten meer voor uitgeven.

[pennywiser]

Jazzy schreef op maandag 4 maart 2024 @ 20:37:
[...]
Ik weet alleen dat publieke certificate authorities er geen certificaten meer voor uitgeven.

Dus kan het certificaat door de browser ook niet gecheckt worden tegen een root CA, meer hoef je niet te weten toch?

[Jazzy]

aad.slingerland schreef op maandag 4 maart 2024 @ 20:36:
[...]


Ik begrijp je redenering helemaal. Maar de consequenties zijjn nogal heftig als ik dit consequent wil gaan doorvoeren.

Dat eerste betwijfel ik. De naam waaronder je een server wilt publiceren staat compleet los van de DNS-naam van je Active Directory. Als jij een interne site wilt publiceren als vorkje.appeltaart.slagroom dan kan dat gewoon, mits je dus een DNS-zone appeltaart.slagroom hebt met daarin een A-record voor vorkje.

[Jazzy]

pennywiser schreef op maandag 4 maart 2024 @ 20:39:
[...]

Dus kan het certificaat door de browser ook niet gecheckt worden tegen een root CA, meer hoef je niet te weten toch?

De CA is een interne hier, die geeft gewoon certificaten uit met een .intra of .local hostname. Voor zover ik het weet is er geen browserfunctie die urls met .intra of .local niet ondersteunt.

[pennywiser]

Jazzy schreef op maandag 4 maart 2024 @ 20:40:
[...]
De CA is een interne hier, die geeft gewoon certificaten uit met een .intra of .local hostname. Voor zover ik het weet is er geen browserfunctie die urls met .intra of .local niet ondersteunt.

Intern betekent (denk ik) door jullie bedrijf uitgegeven. Daarvoor is vooraf in jullie client browsers, of lokaal op het OS een root certificaat geplaatst waar tegen gecheckt wordt. Daarmee is het echter nog steeds een untrustable - self signed certificaat voor de buitenwereld.

Stel dat je met je browser thuis bij jullie intra site kon, kreeg je direct een cn error.

[pennywiser]

Jazzy schreef op maandag 4 maart 2024 @ 20:39:
[...]
Dat eerste betwijfel ik. De naam waaronder je een server wilt publiceren staat compleet los van de DNS-naam van je Active Directory. Als jij een interne site wilt publiceren als vorkje.appeltaart.slagroom dan kan dat gewoon, mits je dus een DNS-zone appeltaart.slagroom hebt met daarin een A-record voor vorkje.

Dat is wel een goeie, in Apache gaat het aanmaken van een subdomein vrij eenvoudig, in IIS kan het niet veel moeilijker zijn (neem ik aan). Maar ik weet vrij weinig van AD en IIS, doe zelf alles onder linux.

[Jazzy]

pennywiser schreef op maandag 4 maart 2024 @ 20:44:
[...]

Intern betekent (denk ik) door jullie bedrijf uitgegeven. Daarvoor is vooraf in jullie client browsers, of lokaal op het OS een root certificaat geplaatst waar tegen gecheckt wordt. Daarmee is het echter nog steeds een untrustable - self signed certificaat voor de buitenwereld.

Dat is het punt niet. Je schreef "...waar browsers tegenwoordig op faulten.". Dat heeft niets met de browser te maken maar of de chain getrust wordt en het subject klopt. Browsers doen tegenwoordig niets anders dan voorheen.

[pennywiser]

Jazzy schreef op maandag 4 maart 2024 @ 20:49:
[...]

Dat is het punt niet. Je schreef "...waar browsers tegenwoordig op faulten.". Dat heeft niets met de browser te maken maar of de chain getrust wordt en het subject klopt. Browsers doen tegenwoordig niets anders dan voorheen.

De browser geeft error toch?

[Semt-x]

pennywiser schreef op maandag 4 maart 2024 @ 20:52:
[...]

De browser geeft error toch?

nee

[pennywiser]

Semt-x schreef op maandag 4 maart 2024 @ 21:34:
[...]


nee
[Afbeelding]

Welke root CA is dat?

[Hero of Time]

pennywiser schreef op maandag 4 maart 2024 @ 20:32:
[...]

Nee ok, ADCS, maar dat is hetzelfde als wat ik bedoel: self signed.

Niet helemaal. Self Signed betekend dat er geen root CA is die het heeft ondertekend. Er is geen chain. Maar dat is bij de TS er wel. Het certificaat is uitgegeven door de interne CA. Daar is niks self signed aan.

[Semt-x]

pennywiser schreef op maandag 4 maart 2024 @ 21:35:
[...]

Welke root CA is dat?

mijn ADCS

[Urk]

pennywiser schreef op maandag 4 maart 2024 @ 20:34:
[...]

Het probleem is (denk ik) de tld .intra waar browsers tegenwoordig op faulten.

Zou in mijn optiek niet uit moeten maken bij een interne CA. Dan zou .whatevertldyouchoose nog geen probleem moeten zijn....

[Question Mark]

pennywiser schreef op maandag 4 maart 2024 @ 19:34:
[...]

Maar zo'n .intra wordt toch door geen enkele browser geaccepteerd in 2024 ook al kloppen de hostnames?

Heb je daar een bron voor? Het enige wat ik weet is dat een interne TLD bv. niet meer als SAN entry geaccepteerd wordt in publieke certificaten. Dat is voor sommige applicaties problematisch.

Wat zijn verder de eigenschappen van het gebruikte certificaat:

• Wat zijn de OID(s)?
• Wat is de subjectnaam?
• Wat is de SAN name?

[ Voor 17% gewijzigd door Question Mark op 05-03-2024 13:44 ]

[pennywiser]

Question Mark schreef op dinsdag 5 maart 2024 @ 13:40:
[...]

Heb je daar een bron voor? Het enige wat ik weet is dat een interne TLD bv. niet meer als SAN entry geaccepteerd wordt in publieke certificaten. Dat is voor sommige applicaties problematisch.

Wat zijn verder de eigenschappen van het gebruikte certificaat:

• Wat zijn de OID(s)?
• Wat is de subjectnaam?
• Wat is de SAN name?

Ik had het over publieke certificaten inderdaad. Volgens mij was er een aantal jaar een soort campagne gaande dat je van interne tld's af moest stappen. In grotere bedrijven wordt dat ook niet meer geaccepteerd als er geauditeerd wordt. Vaak is men al over op normale tld's ook voor intern gebruik.

Blijven gebruiken van .local etc is vragen om problemen volgens mij, geen best practice in elk geval meer.

https://www.brickhost.com...rnal-domains-we-can-help/

[ Voor 12% gewijzigd door pennywiser op 05-03-2024 14:21 ]

[Question Mark]

pennywiser schreef op dinsdag 5 maart 2024 @ 14:01:
[...]
Blijven gebruiken van .local etc is vragen om problemen volgens mij, geen best practice in elk geval meer.

Dat klopt, zie onder andere hier voor de best practice

Naming conventions in Active Directory for computers, domains, sites, and OUs

Met daarbij de sterke aanbeveling om je interne domeinnaam vast te leggen bij een internet registrar om name collisions te voorkomen. En dan zit je automatisch al vast een publieke TLD.

[Jazzy]

pennywiser schreef op dinsdag 5 maart 2024 @ 14:01:
[...]

Ik had het over publieke certificaten inderdaad. Volgens mij was er een aantal jaar een soort campagne gaande dat je van interne tld's af moest stappen.

Niet om die discussie weer opnieuw op te starten, maar je wijst hierbij steeds op browsers. Er is helemaal niets veranderd aan browsers. Het zijn certificate authorities die wat anders zijn gaan doen, browsers kunnen prima werken met een .local, .intra of .slagroom fqdn. Zolang je certificaat aan de eisen voldoet zullen browsers daar niet over klagen, evenmin wget, curl of welke secure client dan ook.

[pennywiser]

Jazzy schreef op dinsdag 5 maart 2024 @ 19:54:
[...]

Niet om die discussie weer opnieuw op te starten, maar je wijst hierbij steeds op browsers. Er is helemaal niets veranderd aan browsers. Het zijn certificate authorities die wat anders zijn gaan doen, browsers kunnen prima werken met een .local, .intra of .slagroom fqdn. Zolang je certificaat aan de eisen voldoet zullen browsers daar niet over klagen, evenmin wget, curl of welke secure client dan ook.

Dat klopt dus niet. Een browser geeft een error als je geen root cert importeert van je .intra of .local. In sommige gevallen (Chrome) kun je dan niet eens verder.

[Hero of Time]

pennywiser schreef op dinsdag 5 maart 2024 @ 19:58:
[...]

Dat klopt dus niet. Een browser geeft een error als je geen root cert importeert van je .intra of .local. In sommige gevallen (Chrome) kun je dan niet eens verder.

Wat dus exact hetzelfde is als je niet het root certificaat hebt van een CA zoals Sectigo.

Je blijft maar rondjes draaien en hetzelfde zeggen terwijl het kant noch wal raakt.

[pennywiser]

3 moderators zitten me op de nek, en ze snappen het allemaal niet.

Ik zeg alleen je moet iets handmatigs doen, anders geeft de browser een error.

Geen eindgebruiker thuis welke jouw root certificaatje gaat installeren. Dus die lopen allemaal tegen errors aan.

Het klopt dus wel wat ik zeg.

[ Voor 67% gewijzigd door pennywiser op 05-03-2024 20:29 ]

[u_nix_we_all]

pennywiser schreef op dinsdag 5 maart 2024 @ 20:27:
3 moderators zitten me op de nek, en ze snappen het allemaal niet.

Volgens mij ben jij degene die het niet snapt. De (interne) CA van het certificaat wordt op de clients gezet. De foutmelding wijst op een fout met de CN en niet ERR_CERT_AUTHORITY_INVALID die je zou krijgen als de CA niet bekend is.

[pennywiser]

u_nix_we_all schreef op dinsdag 5 maart 2024 @ 20:31:
[...]

Volgens mij ben jij degene die het niet snapt. De (interne) CA van het certificaat wordt op de clients gezet. De foutmelding wijst op een fout met de CN en niet ERR_CERT_AUTHORITY_INVALID die je zou krijgen als de CA niet bekend is.

Ja en waarom wil je een intern certificaat, omdat je je security hazard van een .local meuk wilt blijven hosten, en daar ging het nou net over.

[u_nix_we_all]

pennywiser schreef op dinsdag 5 maart 2024 @ 20:33:
[...]

Ja en waarom wil je een intern certificaat, omdat je security hazard van een .local meuk wilt blijven hosten, en daar ging het nou net over.

Nee het ging erom dat de TS een foutmelding kreeg en deze wil verhelpen. Niet om een discussie of het gebruik van een interne CA een good practice, onveilig of zelfs onmogelijk is.

[Quad]

Heb je wel een certificaat aangevraagd? Want zover ik weet kan je geen certificaat krijgen op een .intra domein, omdat deze TLD niet publiekelijk beschikbaar is.

Dan is het geheel logisch dat je foutmeldingen krijgt op HTTPS.
En een normaal .nl met intra voorvoegsel hoeft helemaal geen big deal te zijn. Je lokale AD staat los van wat jij aanbiedt met een website. Ook al is het intern.

Overigens adviseer ik om informatie omtrent de URL/domein te anonimiseren, deze voegen niets toe op het forum.

(je kan prima verwijzen naar domein.intra of intra.domein.nl, dan begrijpen wij het net zo goed. )

[ Voor 21% gewijzigd door Quad op 05-03-2024 20:41 ]

[pennywiser]

u_nix_we_all schreef op dinsdag 5 maart 2024 @ 20:35:
[...]

Nee het ging erom dat de TS een foutmelding kreeg en deze wil verhelpen. Niet om een discussie of het gebruik van een interne CA een good practice, onveilig of zelfs onmogelijk is.

Laatste reactie dan. Het ligt er vast aan hoe ik het zeg of iets dergelijks, waarom er zo over gevallen wordt, sorry wie daar aanstoot aan neemt, maar ik bedoel het gewoon goed, probeer gewoon te helpen, en de aanbeveling in de toekomst na te streven niet meer verder te gaan met .local domeinen lijkt me prima onderdeel van het gesprek hier.

[Paul]

"NET::ERR_CERT_COMMON_NAME_INVALID" is een beetje verwarrend, wat het betekent is niet dat de naam niet in het subject staat als CN, maar dat de naam niet voorkomt als Subject Alternate Name. Browsers kijken tegenwoordig niet meer naar de CN, maar naar de SAN. Je kunt maar één CN hebben, en heel veel SAN's.

Je moet bij het aanmaken zorgen dat je de SAN(s) ook opgeeft, want ADCS zet deze er niet zelf bij.

@aad.slingerland, kun je de public key hier posten? Het enige 'geheime' hieraan zou eventueel de domeinnaam kunnen zijn, en die heb je al gepost; je webserver stuurt de public key naar iedereen die een webrequest naar je server doet. Dit in tegenstelling tot de private key, die moet je koste wat kost privé houden

Met de public key kunnen we zien wat de diverse waardes zijn, met name dus de Subject Alternate Names

Quad schreef op dinsdag 5 maart 2024 @ 20:39:
Dan is het geheel logisch dat je foutmeldingen krijgt op HTTPS.

Dan zou je een melding krijgen dat de uitgever niet vertrouwd wordt; ik weet even niet in welke volgorde browsers dingen controleren, maar de foutmelding die @aad.slingerland nu krijgt wijst niet op een self-signed certificaat of een niet-vertrouwde root.

Quad schreef op dinsdag 5 maart 2024 @ 20:39:
Overigens adviseer ik om informatie omtrent de URL/domein te anonimiseren, deze voegen niets toe op het forum.

Ik adviseer juist om dat niet te doen. Het voegt niets toe om het te anonimiseren want het is een interne naam waar we niets mee kunnen, en wekt alleen maar nodeloos verwarring als je het de ene keer anders anoniem maakt dan de andere keer.

[deHakkelaar]

pennywiser schreef op dinsdag 5 maart 2024 @ 14:01:
Blijven gebruiken van .local etc is vragen om problemen volgens mij, geen best practice in elk geval meer.

https://www.brickhost.com...rnal-domains-we-can-help/

Het gebruiken van .local als search/suffix domain voor normale DNS kan conflicteren met mDNS:

The domain name .local is a special-use domain name reserved by the Internet Engineering Task Force (IETF) so that it may not be installed as a top-level domain in the Domain Name System (DNS) of the Internet. As such it is similar to the other special domain names, such as .localhost.[1] However, .local has since been designated for use in link-local networking, in applications of multicast DNS (mDNS)[2] and zero-configuration networking (zeroconf) so that DNS service may be established without local installations of conventional DNS infrastructure on local area networks.

Wikipedia: .local

https://www.rfc-editor.org/rfc/rfc6762.html

Dat is de enige reden waarom .local wordt afgeraden.
Zie ook andere gereserveerde namen waaronder bv home.arpa. voor thuis:
https://www.iana.org/assi...al-use-domain-names.xhtml

Geen idee waarom dat Brickhost linkje dit niet duidelijk uitlegt.
Die RFC die ze linken rept geen woord over het .local search/suffix domein.

[Jazzy]

Jazzy schreef op maandag 4 maart 2024 @ 20:32:
Bekijk het certificaat dan eens via de browser. De naam die je in de adresbalk van je browser typt moet op het certificaat staan bij Onderwerp en dan nogmaals bij Alternatieve naam voor entiteit van certificaat. Of de Engelstalige equivalenten van die termen.

@aad.slingerland Kan me voorstellen dat de hoeveelheid reacties wat overweldigend is. Los van de op zich waardevolle adviezen om een andere richting in te slaan moet je huidige situatie gewoon kunnen werken. Om daar even naar terug te gaan, zou je bovenstaande eens willen controleren?

[deHakkelaar]

Jazzy schreef op woensdag 6 maart 2024 @ 13:38:
Om daar even naar terug te gaan, zou je bovenstaande eens willen controleren?

@aad.slingerland , op een Linux client zou je onder doen:

$ dig +short tweakers.net a
213.239.154.30

$ openssl s_client -connect 213.239.154.30:443 -servername tweakers.net </dev/null 2>/dev/null | openssl x509 -noout -text | grep 'Subject:.* CN =\|Alternative Name\|DNS:'
        Subject: CN = *.tweakers.net
            X509v3 Subject Alternative Name:
                DNS:*.hardware.info, DNS:*.tweakblogs.net, DNS:*.tweakers.be, DNS:*.tweakers.mobi, DNS:*.tweakers.net, DNS:*.tweakers.nl, DNS:*.tweakers.tv, DNS:*.tweakimg.net, DNS:*.tweakzones.net, DNS:hardware.info, DNS:tweakblogs.net, DNS:tweakers.be, DNS:tweakers.mobi, DNS:tweakers.net, DNS:tweakers.nl, DNS:tweakers.tv, DNS:tweakimg.net, DNS:tweakzones.net