[BESVARET] Spørgsmål omkring Certificater
Hey.
Jeg har et spørgsmål omkring certificater som jeg gerne kunne tænke mig at høre om nogen ved noget om.
Jeg arbejder på et projekt - hvor jeg har en VPN-server - hvor jeg har flere klienter (80 lokationer) på.
Hver lokation er bygget op på samme måde.
1 stk VPN router - VPN-IP: 10.98.98.50 (+1 for hver lokation)
Subnet range: 192.168.0.1/24
SQL-Server - 192.168.0.2
PLC - 192.168.0.3 - Jeg har på PLC controlleren en webserver indbygget.
Mit spørgsmål er så:
PLC kommer med software - med en apache Controller - men et untrusted certifikat oprettet til Localhost altså https://127.0.0.1 - Men jeg får en advarsel hver gang jeg tilgår den den igennem Browseren.
Kan jeg på nogen måde få et valideret certificat til denne Webserver som reelt ikke har noget navn. Den kan reelt kun tilgå's via IP - som skifter for hver lokation, men hvor det er portforwarded til samme LAN-ip?
Dvs samme certificat ligger på 10.98.98.50:443, 10.98.98.51:443 osv men er reelt gyldigt for alle der ser?
Dette er systemer der er svært tilgængelige - og replikerer data hjem til HQ - Men det skulle gerne være mulighed for evt lokalt at se de værdier mm der er PT - så derfor er det vigtigt at se de data, Men hvis der kommer advarsel for hver lokation - ville det være klart at foretrække hvis man kunne få det lavet et Certifikat der valideres uanset hvad.
Ville det lykkedes nemt hvis man kalder PLC samme samme hostnavn på alle lokationer og dermed kun skulle bruge et certifikat?
For mig er det vigtige at hvis man skal bruge https://10.98.98.50 - så skal certifikatet været valideret. (vi teknikere kan nok sige OK - osv - mens ikke IT-kyndige går i panik ovewr denne advarsel)
Hvordan kan jeg klare dette - helst med et valideret certifikat
Jeg har et spørgsmål omkring certificater som jeg gerne kunne tænke mig at høre om nogen ved noget om.
Jeg arbejder på et projekt - hvor jeg har en VPN-server - hvor jeg har flere klienter (80 lokationer) på.
Hver lokation er bygget op på samme måde.
1 stk VPN router - VPN-IP: 10.98.98.50 (+1 for hver lokation)
Subnet range: 192.168.0.1/24
SQL-Server - 192.168.0.2
PLC - 192.168.0.3 - Jeg har på PLC controlleren en webserver indbygget.
Mit spørgsmål er så:
PLC kommer med software - med en apache Controller - men et untrusted certifikat oprettet til Localhost altså https://127.0.0.1 - Men jeg får en advarsel hver gang jeg tilgår den den igennem Browseren.
Kan jeg på nogen måde få et valideret certificat til denne Webserver som reelt ikke har noget navn. Den kan reelt kun tilgå's via IP - som skifter for hver lokation, men hvor det er portforwarded til samme LAN-ip?
Dvs samme certificat ligger på 10.98.98.50:443, 10.98.98.51:443 osv men er reelt gyldigt for alle der ser?
Dette er systemer der er svært tilgængelige - og replikerer data hjem til HQ - Men det skulle gerne være mulighed for evt lokalt at se de værdier mm der er PT - så derfor er det vigtigt at se de data, Men hvis der kommer advarsel for hver lokation - ville det være klart at foretrække hvis man kunne få det lavet et Certifikat der valideres uanset hvad.
Ville det lykkedes nemt hvis man kalder PLC samme samme hostnavn på alle lokationer og dermed kun skulle bruge et certifikat?
For mig er det vigtige at hvis man skal bruge https://10.98.98.50 - så skal certifikatet været valideret. (vi teknikere kan nok sige OK - osv - mens ikke IT-kyndige går i panik ovewr denne advarsel)
Hvordan kan jeg klare dette - helst med et valideret certifikat
Kommentarer13
Årsagen til browseren
For at være med i puljen af rod-certifikater i de fleste OS og browsere er det ikke længere tilladt at underskrive certifikater op imod IP adresser. Det er faktisk kun tilladt at underskrive et certifikat hvis det kan verificeres online at du ejer domænet.
Jeg skal ikke kunne sige om det er en løsning for dig men du kan generere dit eget rodcertifikat og så bede dine kunder om at installere dette. Herefter skal du så bare sikre at alle certifikater der bruges i din løsning er underskrevet med dit hjemmelavet rodcertifikat. Alternativt kan du sikre at alle dine services bruger samme certifikat som så har angivet såkaldt alias således det kan bruges til flere IP addresser (skalerer så ikke så godt da du så skal udgive nyt certifikat hver gang du bruger en ny IP i din pulje).
Ellers er din eneste løsning at gøre så din service kan tilgås offentligt ude på det store internet og derved tilknytte dine IP adresser til domænenavne (kan jo sagtens være subdomæne).
Hej Julemand.
Tal for din
Tal for din uddybning. Så var tingene også der hvor jeg mente de var.
Problemet er reelt - hver lokation er reelt et skib og derfor ikke tilgængelig via Offenlig IP - men skjult bag et NATtet netværk.
Tak for forklaring og tid
Hej Peque
Jeg arbejder
Jeg arbejder sammen med en i vores IT virksomhed der nærmest VPN GUD. Hvis I er interesseret tror jeg godt han vil komme med en løsning, men det er desværre ikke noget der kan gøres til 0,-.
Hey Domiini
Det er ikke VPN
Det er ikke VPN eller lign der er problemet :-) Syntes jeg jeg har rimeligt godt styr på dette .
Mit problem er reelt en PLC med en Apacheserver - jeg har f.eks 100 forskellige PLC'er hvor alle har samme IP på diverse lokationer. Kan jeg erstatte dette certificat med et valideret
Deres egen Interne Website - kører via https - Men hvor man så ser denne error omkring Certificatet - når nu det er selvudstedt.
Der er ingen domæneeller andet indblandet ellers - det eneste er at PLC har IP 192.168.0.3. og der er ikke muligt for offenligt adgang, kun hvis man er logget ind på VPN
Prøv at kigge på
Letencrypt er kun
Letencrypt er kun understøttet til en public IP ikke en klasseC IP.
Umiddelbart som jeg har læst deres dokumentation - er det kun hvis det er en public IP
#6
Yep, som jeg skrev i mit
Yep, som jeg skrev i mit indlæg så må man ikke længere (hvis du vil være en del af de fleste browsere og operativsystem certifikat puljer) udstede certifikater til nogen former for IP adresser, eller domænenavne som ikke kan tilgås offentligt. Så hvis man har systemer der kun kan tilgås via VPN (uanset om det er domæner eller IP'er) så må man ud i selv at lave et rodcertifikat til sine services.
Jeg skal måske lige hurtigt
plc.example.com - 192.168.0.3
Certifikatet du har fået udstedt skal du så kopiere ind på alle dine plc hosts. På den måde burde det virke. Det kan være Let's Encrypt er lidt bøvlet her hvis du ikke kan automatisere denne process (igen, for stjernecertifikater skal de verificere dit domæne så der skal tilføjes automatisk en TXT record til din DNS server med mindre du vil gøre dette manuelt hver 90 dage).
Hej Julemand.
Var inde og
Var inde og google denne mulighed tidligere - men må indtrømme det er at skyde gråspurve med kanoner - Det var kun i tilfælde externe kom på og skulle se data fra lokationen direkte istedet for at se det i HQ.
men må indtrømme det
Siden du synes det, kan du så ikke klare problemet ved at informere eksterne angående advarslen, eksempelvis fra et HTML, der viderestiller dem til data, enten fra et klikbart link eller automatisk? Infoen kan gøres meget enkel fra et indledende HTML dokument.
Som jeg forstår det er der kun tale om intranet. Dvs en webserver uden adgang til og fra internettet af sikkerhedsårsager. Er det korrekt?
Hvad mener du med HQ? Er det headquarter? Hvis du skal passe på med hvad du fortæller, så har jeg fuld forståelse ...
Hey Frogmaster.Ja HQ -
Hey Frogmaster.
Ja HQ - er headquarter. og ja er en smule begrænset af hvad jeg må fortælle.
Som grundlæggende er det på et sib hvor vi indsamler data og replikerer dette hjem til HQ. Dog er der flere instrumenter og PLC som har deres eget Interface, og dette interface kører på et selfsignet Cert - og derfor melder fejl.
Der er intet domæne eller Lign - så et DNS er ikke muligt.
Hovedsagligt er det om jeg skal tvinge over på almindelig HTTP - eller om jeg kan få et valideret cert til 192.168.0.3 - hvilket jeg ser som ikke muligt.
Derfor må vi enten acceptere det bliver http eller begrund dette valg omkring https i dokumentationen! Men korrekt denne PLC har intet at gøre på nettet
Jo muligheden er da også at informere om problemet - men det ser mere proff ud - hvis det var valideret.
Jeg skal forvente at det er totalte PC-mongoler der skal kunne finde ud af det :-)
#11
Men der er vel intet i
Men der er vel intet i vejen for at bruge alm. HTTP hvis du alligevel kommunikerer via din egen VPN?
Nej det er intet i
Nej det er intet i vejen for at tvinge det over http fremfor https - specielt når det internt igennem VPN.
Men det var hvis det var muligt at få certificat der kunne validere dette - ville det være at foretrække