Het certificaat is uitgegeven door de DoD. Verder in orde, zie eigenschappen, certificaten, alleen niet van een standaard, openbare, certificerings-instantie.

En leg een leek eens uit wat zo'n sertificaat inhoud en wat de VS hiermee te maken heeft als je wilt. Ben zeer benieuwd.

Greetz

\Wij vragen ons af waarom en wat je nou op die website zocht..??????

Sectrust.ams.OSD/Crew.

Hier, in het engels:
http://en.wikipedia.org/wiki/Public_key_certificate
In militair formaat Amerikaans:
http://www.dlis.dla.mil/pdfs/pki_ieinstr.pdf

Het voordeel van een https verbinding boven een http verbinding is:
(A) dat de hele verbinding tussen jouw PC en het IP-adres van de site waarmee jouw browser de verbinding heeft opgezet zodanig is versleuteld dat niemand mee kan kijken (of data on-the-fly kan wijzigen)
(B) dat je zeker weet dat je verbinding hebt met de site waarvan de URL in je browser te zien is

Als je niet zeker weet dat (B) klopt heb je eigenlijk niks aan (A), immers een site "onderweg" (man-in-the-middle) zou zich kunnen voordoen als de site waar je mee wilt communiceren, en dus alles meekijken, wijzigen, of in het geheel niet doorsturen naar de echte site. Om zowel (A) als (B) te laten kloppen zijn een aantal denkstappen nodig.

Public Key Encryptie
Om te beginnen wordt er gebruik gemaakt van Public Key Encryptie. Simpel gezegd gaat het daarbij om een slot met twee "complementaire" sleutels: met een van beide sleutels kun je de boel op slot doen (gegevens versleutelen), maar niet ontgrendelen (gegevens weer toegankelijk maken); dat kan alleen met de andere sleutel!

Het is wat vereenvoudigd, maar de sleutel om gegevens mee te versleutelen noem je de public key en die geef je aan iedereen die hem wil hebben, de andere noem je de private key en die houdt de website strikt geheim. Als jij de public key van een website hebt, en alle gegevens die je daar naar toe stuurt daarmee versleutelt, kan alleen degene die de bijbehorende private key heeft die gegevens uitpakken; alleen die website dus.

Klinkt goed, maar hoe weet je zeker dat de public key die jij hebt echt van die website is die jij bedoelt, en niet van een website die zich voordoet als zodanig? Dus wel (A), maar nog geen (B)! Dat is waar certificaten voor worden gebruikt.

Certificaten
In de ICT wereld is een certificaat niets anders dan een bestand met een digitale handtekening eronder. Bij een SSL server certificaat (die bij https wordt gebruikt) zitten in dat certificaat onder andere de volgende gegevens: de ingangs- en einddatum, de hostname van de website en de public key daarvan. Tijdens het opzetten van de https verbinding stuurt de website haar certificaat naar jouw browser, zodat jij over de public key beschikt - en meteen kan checken of het certificaat nog geldig is en of de hostname hetzelfde is als in de URL-balk van je webbrowser. De digitale handtekening onder dat certificaat wordt gebruikt om vast te stellen dat de inhoud van het certificaat, sinds ondertekening, niet is gewijzigd.

Certificate Authority (CA)
Maar wie zet die handtekening eigenlijk? Normaal gesproken doet een zogenaamde Certificate Authority (kortweg CA) dat. Een CA is een soort internet notaris. Essentieel daarbij is dat die CA controleert dat degene die dat certificaat wil laten ondertekenen, echt de website in zijn bezit heeft waarvan de hostame in het certificaat genoemd staat. Effectief garandeert een CA dus middels het ondertekenen van een certificaat dat een bepaalde public key bij een bepaalde hostname hoort.

Digitale Handtekening
Zo'n digitale handtekening maakt trouwens ook gebruik van Public Key Encryptie, d.w.z. dat de CA haar private key gebruikt voor het zetten van de digitale handtekening, waarvan de echtheid alleen kan worden vastgesteld met behulp van de bijbehorende public key. En effectief worden bij elke webbrowser alle public keys van alle gerenommeerde CA's meegeleverd (feitelijk worden ook die weer in certificaten (zogenaamde root certificaten, type self-signed) meegeleverd, maar dat boeit even niet omdat niemand die op echtheid kan controleren - je zult je webbrowser-leverancier erop moeten vertrouwen dat ie de juiste public keys van alle belangrijke en betrouwbare CA's meelevert).

"Onbekende" CA
Wat is er nu aan de hand met "www.jagcnet.army.mil"? Het certificaat daarvan is ondertekend door een CA wiens public key niet is meegeleverd met jouw browser (je hebt geen root-certificaat van DOD-13 in je webbrowser). Daardoor garandeert niemand jouw browser (en dus jou) dat de public key in het ontvangen certificaat van "de echte" www.jagcnet.army.mil is, en daarom slaat de webbrowser alarm. In Firefox kun je overigens wel een (eenmalige of permanente) exception aanmaken. Bij een permanente exception bewaart Firefox het certificaat en controleert elke keer bij ontvangst of deze nog steeds hetzelfde is; zo ja dan wordt niet opnieuw gewaarschuwd. Goed nadenken en zomogelijk de echtheid verifieren dus voordat je zo'n permanente uitzondering toestaat.

PS het bovenstaande is een vereenvoudigde weergave. Versleutelen van veel data met public key encryptie kost te veel performance. Daarom wordt aan het begin van een verbinding een normale, on-the-fly gegenereerde symmetrische sleutel uitgewisseld; alleen die sleutel wordt met public key encryptie ingepakt, verzonden en uitgepakt, waarna de rest van de verbinding met die symmetrische sleutel wordt versleuteld. In een SSL certificaat zitten meer gegevens, waaronder de naam etc. van de CA (op die manier kunnen Ilja. _\\// en ik zien wie in dit gevalde CA is).

Snappie?

Ik heb hier nog wel een simple oplossing voor, deze meling veroozaakt bij mij veel iritatie en ellende. Kan iemand mij vertelen hoe ik dat Authority system uit mijn webbrowser kan slopen. In het register kan ik de sleutel vinden waar die Certificate worden opgeslagen, maar ik heb helemaal geen behoefde om op een website van de US defensie een kijkje tenemen. Dus blockeer ik deze website maar in de hotst file!

# jagcnet.army.mil
127.0.0.1 www.jagcnet.army.mil
127.0.0.1 jagcnet.army.mil
127.0.0.1 dco.dod.mil
127.0.0.1 www.dco.dod.mil
127.0.0.1 akocac.us.army.mil
127.0.0.1 www.akocac.us.army.mil
127.0.0.1 jagcnet2.army.mil
127.0.0.1 www.jagcnet2.army.mil
127.0.0.1 crl.disa.mil
127.0.0.1 www.crl.disa.mil
127.0.0.1 disa.mil
127.0.0.1 www.disa.mil
127.0.0.1 ocsp.disa.mi
127.0.0.1 dtic.mil
127.0.0.1 www.dod.mil
127.0.0.1 dod.mil
127.0.0.1 www.dtic.mil
127.0.0.1 www.ocsp.disa.mi
127.0.0.1 nic.mil
127.0.0.1 www.nic.mil
127.0.0.1 ca-3.c3pki.chamb.disa.mil
127.0.0.1 www.ca-3.c3pki.chamb.disa.mil
127.0.0.1 ca-4.c3pki.den.disa.mil
127.0.0.1 www.ca-4.c3pki.den.disa.mil

Als je dat dan zo doet in je hostfile:

127.0.0.1 *.mil

Dan kom je bij geen enkele site binnen het militaire domein meer binnen. Met deze: 127.0.0.1 *.* heb je ook geen last meer van certificaten van alle andere domeinen.

Die certificaten worden niet in je register opgeslagen overigens. Maar leef je uit, sloop je register maar, zoek naar certificatestore, & vergeet de CLSID niet, bv: HKEY_CLASSES_ROOT\CertificateAuthority.Config.

Bitwiper: Ik hoop dat je het allemaal al eens opgeschreven had & het naar hier hebt kunnen kopieren zonder al te veel werk, alhoewel het voor degenen die het wel echt willen weten, best interessant is.

Verder is het bij U.S. .mil sites zo dat als je van binnen uit het domein naar zo'n pagina gaat, die waarschuwing niet gegeven worden omdat de servers het dan zelf authenticeren.

Wat ik daar dan weer niet van snap, is dat in feite de Architect, de Vader & de Moeder, & nog steeds het Opperhoofd van het Internet, blijkbaar niet in staat is om een publiek certificaat in te stellen.
Zal er wel mee te maken dat ze pas sinds kort wettelijk verplicht alles moeten versleutelen & beveiligen...

Dat is onjuist. Voor zover ik weet zijn er geen besturingssystemen die wildcards in de hosts file ondersteunen. Windows en Linux doen dit in elk geval niet.

Dit was bewust uit het blote hoofd, da's een goede oefening en zorgt ervoor dat ik de info kan reproduceren.

Nee, het zijn wel degelijk de webbrowsers die checken of ze echt met de bedoelde server praten. Alleen vertrouwt de USA defensie kennelijk geen enkele publieke CA. Ik vermoed dat ze PC's met webbrowsers uitleveren met daarin uitsluitend hun eigen root certificaten, en geen enkele publieke. Behalve een verschil tussen EV certificaten en gewone laten webbrowsers voor zover ik weet geen verschil zien in de mate van trust: er is wel of geen sprake van een slotje. Je moet het certificaat (vaak meerdere) openen om achter de chain of trust te komen. En een ketting is zo sterk als...

Ik denk dat ze Microsoft, Mozilla en andere webbrowsermakers onvoldoende vertrouwen als het gaat om welke rootcertificaten zij meeleveren. Lijkt me terecht, het systeem is zo lek als een mandje, oftewel 't is leuk voor consumenten.

Hè, gaat m'n graptrapje voor Anoniem... ;-)
Ik neem aan dat er zoiets aan de hand is, want tijdens mijn "onderzoek" heb ik ergens gelezen dat de server van de DoD dat zelf verifieert, dus als je bv. op een client in het Pentagon zit te surfen of zo...

Ik heb trouwens wel net de methode gevonden om die waarschuwingen weg te krijgen: De eerder genoemde pki_ieinstr.pdf
geeft de juiste minimale instructies maar de gegeven links kloppen niet. Ondertussen heb ik dus alle verkrijgbare militaire certificaten in m'n IE zitten, maar deze werkten:
Minimaal volgens pdf:
http://dodpki.c3pki.chamb.disa.mil/legacyroot.html
Bovenstaande link staat hier weer onderaan als legacy (legaat, verouderd):
http://dodpki.c3pki.chamb.disa.mil/rootca.html
Na Opslaan Open Map, RMK, Installeer Certificaat, volg aanwijzingen scherm, kies Automatisch, volgende, etc. tot Certificaat succesvol geïnstalleerd, Ok, IE herstarten. Vanaf dan kom je in alle .mil zonder waarschuwing, aangenomen dat die niet echt top secret zijn. :-)

En wat staat er precies in die DOD certificaat; zo iets van open de poort wij zijn het de USA defensie en we zijn een vertrouwelijk website en dan moet je ons toegang verlenen, dus ga je niet akoord met het DOD certificaat verleen je geen toestemen en wordt je poort geweigerd door firewall MIL, wat die jagcnet.army.mil wil javascript toepassen op je webbrowser!

Hoewel de benodigde Root CA ook in mijn browser ontbreekt heeft de beheerder van de server in kwestie ook een fout gemaakt bij de installatie van het certificaat. Als het server certificaat correct is geinstalleerd moet de server volgens RFC 2246 tijdens het opzetten van de SSL verbinding namelijk het intermediate CA certificaat (of -certificaten) aan de client verstrekken. Deze server doet dat niet. Met behulp van het volgende OpenSSL commando kun je nagaan welke certificaten tijdens de SSL handshake door de server aan de client worden verstrekt:

openssl s_client -connect www.jagcnet.army.mil:443 -showcerts

Als een client die wel beschikt over de juiste Root CA met deze server verbinding maakt en nog niet beschikt over de juiste intermediate CA mist er op de client nog steeds een schakel in de certificate chain en kan het server certificaat niet gevalideerd worden. Dit is een van de meest voorkomende fouten bij de installatie van certificaten en komt ook regelmatig voor bij bedrijven die Extended Validation certificaten gebruiken.