Gratis SSL-certifikat från let's encrypt
 

Let's encrypt öppnade precis upp för allmänheten. Ett bra tips för er som behöver gratis SSL-certifikat.

Pressmeddelande: https://letsencrypt.org/2015/12/03/e...blic-beta.html

Värt att nämna är att för att kunna nyttja letsencrypt.org måste deras Python-baserade klient installeras på servern i fråga. Det vill säga, inte riktigt för alla...

Du behöver inte installera något på servern utan de räcker med att du genererar alla certifikat på din lokala dator för å sedan flytta över dom till servern. Skulle även gissa på att du manuellt kan generera certifikaten lokalt på datorn utan deras skript (å således slipper python), men att de manuella arbetet då blir något större.

Jag vill istället tipsa om CloudFlare som även ger gratis https sedan något år eller så tillbaka och sedan idag även skickar med HTTP/2 med SPDY som fallback till de webbläsare som inte stödjer HTTP/2.

Ser några problem med deras lösning gentemot letsencrypt.

1. CloudFlare körs i mellan ens site och slutanvändaren
2. Certifikaten från CF tar ett dygn att utfärda
3. Utfärdas gratis av en icke-ideell organisation (du blev helt plötsligt produkten)
4. Manuell hantering av certifikaten. LE tillåter dig att generera, administrera, förnya och installera certifikaten direkt på servern. Processen kan även, enligt de jag läst, automatiseras när ett cert behöver förnyas.

Även om det faktiskt är möjligt (man måste utöver det validera domänen) så blir det riktigt extra jobbigt med tanke på att de certen bara lever i 90 dagar.

Läste något om de för ett tag sedan men visste inte att levnadstiden var så kort. Körde precis skripten isf. Tog 1 min att generera och installera certen på servern. Bra mycket smidigare än den manuella processen jag är van vid.

Har testat det själv på några siter nu under ett par veckor och måste säga att det är jäkligt smidigt att generera ut nya cert med Letsencrypt.
Däremot är det kanske inte riktigt redo för totala noviser.

Läste precis anledning till varför livstiden för certifikaten är så kort.

Deras lösning är istället att korta ner livstiden så att informationen om de tillbakadragna certifikatet inte behöver finnas på nätet lika länge.

Kul ska prövas. Var orolig att de inte skulle stödja alla vanliga äldre klienter men det ser ut att inte vara något problem https://community.letsencrypt.org/t/...s-encrypt/4394.

Här är en helt ny klient till Lets Encrypt på under 200 rader som kan förnya certs genom cron job: https://github.com/diafygi/acme-tiny

Grymt! Tack för tipset!

Eller så scriptar man bara ett eget.

LetsEncrypt är hur grymt som helst, rekommenderas!

Någon som har koll på hur bra deras cert fungerar (eller inte) på mobila webbläsare? Eller andra issues för den delen...

Det funkar på allt som jag kollat på, det är precis som vilket rapidSSL cert som helst.

Här är ett test ifrån min setup https://www.ssllabs.com/ssltest/anal...swedishhost.se

Ser riktigt lovande ut. Tack för länken!

Jag använder https://forge.laravel.com för att deploya många av mina applikationer och där finns Let's encrypt tillgängligt på sajten i fråga genom ett knapptryck. Rekommenderas om du kör PHP projekt!

Fungerar klockrent! För den som är intresserad så har Plesk det integrerat via enkel knapptryckning i senaste versionen.

Även DirectAdmin har haft det en tid nu. Riktigt smidigt.

Det enda negativa jag stött på är avsaknaden av stöd för IDN domäner men det är på gång :D

https://letsencrypt.org/upcoming-features/

Kändes inte helt OK att köra ett perl-script med root-rättigheter som uppdaterar sig själv via nätet ...

Jag har gjort ett script i NodeJS (JavaScript) för er som kör Nginx:

https://github.com/Z3TA/letsencrypt-nodejs-nginx

Fritt att kopiera och modifiera.

certbot och följande crontab rad löser problemet:

https://bjornjohansen.no/lets-encrypt-for-nginx
https://www.digitalocean.com/communi...n-ubuntu-14-04

Även cPanel har nu detta inbyggt via deras AutoSSL funktion i v58. Man måste aktivera det bara via ett script man kör som root, sen så fungerar det riktigt smidigt!

Har man inte tillgång till root utan kör bara vanligt webbhotellskonto kan man använda "WP Encrypt" i Wordpress och sedan läsa key-file som man lägger in i t.ex. Cpanel som en vanlig SSL installation.

Pluginet kan autouppdatera certifikatet efter 90 dagar med.

SSL hanteras enklast sen i Wordpress med pluginet "Really Simple SSL".

Tog en snabb titt på koden. Du har en del try-catch block på asynkrona metod-anrop som inte kommer fungera. Ett tips är att använda en linter om du är osäker på vad som fungerar och ej.

Edit: EsLint med Googles regler ger 499 fel och Flow Type runt 100.

Tack för din feedback! readFileSync är dock en synkron funktion !!

Angående "linters" så är min erfarenhet att de nästan aldrig upptäcker buggar. Av de 499 "felen" du hittade beror troligtvis de flesta på att jag använder tab i stället för mellanslag som indentering ...

Helt rätt, mitt fel.

Stängde av indenteringsreglerna för filen. En majoritet försvann, men 196 återstår. Några exempel är '==' istället för '===', dubbeldeklarering av variabler, ohanterade callback-fel, importering utanför headern, djup nästade callback, långa rader, användning av variabler ej ännu deklarerade.

Vad är din uppfattning av en linter, dess användning och vilken funktion anser du att den fyller?

En linter kan vara bra om man arbetar i ett team, och kommit överens om att koden ska se ut på ett speciellt sätt. Jag tycker dock det läggs allt för mycket tid på meta-programmering, till exempel omstrukturering av koden för att hålla raderna under 80 tecken, vilket ibland kan kräva kluriga lösningar som gör koden svårare att förstå.



importering i headern uppmanar till att använda globala variabler! Jag försöker undvika globala variabler så långt som möjligt. En unik grej med modul-systemet common-js är att man kan importera moduler lokalt!! Koden blir så mycket lättare att förstå då.


'==' istället för '===' ... Om jag skulle skriva if(foo===undefined) skulle jag även behöva lägga till if(foo===null). Så det är lite av en bekvämlighet, jag fångar två flugor i en smäll. Man bör dock undvika att jämföra olika typer. Ex: if("42"==42) . Men vad hjälper det om det blir false i stället för true !? Eventuella buggar kvarstår ändå. Man bör i stället konvertera alla nummer till den typ man vill ha. Ex: var age=parseInt(request.form.age) för att vara på den säkra sidan.

Den är inte heller till för att upptäcka buggar, det har du andra verktyg till. Den är till för att få en bättre och mer överskådlig kodstruktur för alla som tittar på koden och minska risken för att man skapar buggar från första början.

Kan du rekommendera några verktyg som hittar buggar i JavaScript?

Lycka till att hitta sånt till ett otypat och direkt tolkat programmeringsspråk.
Lint/hint är bara ämnade för kodkvalité.

Nej, de primära syftet är att hitta kod som rent semantiskt är rätt, alltså där kompilatorn säger ok, men där chansen är stor att du och interpretatorn har delade meningar. Te.x semikolon och den icke-determinism som avsaknaden kan innebära.

Meta-programmering har inget med struktur att göra.

Förstår du de statistiska sambandet mellan buggar och kodkomplexitet?

Nej. Importering av extern kod i de flesta Javascript-JIT är blockerande. Gör du en import mitt i koden så blockar detta hela eventloopen och då även gränssnittet.

För att inte nämna de optimeringsproblem din JIT utsätts för när kod med sidoeffekter laddas in under körning. Har du te.x koll på hur icke-deterministisk kod påverkar din prestanda?

Så vitt jag vet så tillåter alla importeringssystem detta.

I de fallet är `if(foo)` att rekommendera. Att du försöker jämföra med undefined och null tyder på att du har andra, mer fundamentala problem, i din implementering. Fråga dig själv varför dessa världen introducerades från första början- Odefinderade världen representerar ett odefinerat tillstånd, alltså en bugg.

Tvetydlig kod är vad som skapar buggar (och i de här fallet även prestandaproblem). På samma vis som `==` operatorn inte ska användas så ska `++` inte användas.

Om vi bortsätt från koden du postade så är de största misstaget du gör att tro att du är smartare än miljön du befinner dig i. För att kunna avgöra huruvida felen lintern påpekade är värt att fixa eller ej så behöver du grundläggande kunskap inom bl.a beräkningsmodeller, kompilatorer, typsystem, matematisk statistik och miljön koden ska köras i, te.x Googles V8-motor.

Varför inte bygga upp nödvändig kunskap parallellt och förlita dig på de verktyg som finns?

FlowType (https://flowtype.org/) hjälper till med de här. Den kan, utan annoteringar, härleda typer och fel i din kod. Te.x `function(x) {x.length}(null) // => Error: null is not a string;

Vet inte om gratis är bra och går att lita på i längden. Själv köpte jag en certifikat från Namecheap https://www.namecheap.com/security/s...tificates.aspx finns för $10 dollar per år och dyrare beroende på vad man behöver.

Moduler cachas i NodeJS. Och lokala variabler går ofta lite fortare att hämta! Men även om det gjorde koden segare så är det onödigt att optimera utan att mäta först!


Det bästa är if(foo === undefined || foo === null)

Det näst bästa är if(foo == undefined)

Men det sämsta är if(!foo) för att det finns för många "false-positive", det skulle även trigga false, noll, strängen noll, tom sträng, tom array, eller array med noll, vilket ibland är ett godtagbart värde.

Du har rätt i att undefined ofta tyder på en bugg ...

Ta följande kod som exempel:

Lintern klagar på följande:

1:1 - Expected a function expression.
1:1 - Missing JSDoc comment.
1:1 - Use the global form of 'use strict'.
1:14 - Missing space before function parentheses.
1:15 - Identifier name 'a' is too short (< 2).
1:18 - Identifier name 'b' is too short (< 2).
1:21 - Block must be padded by blank lines.
2:2 - Expected indentation of 4 space characters but found 0.
2:2 - Unexpected console statement.
3:1 - Block must be padded by blank lines.
4:2 - Newline required at end of file but not found.
4:6 - No magic number: 1. (no-magic-numbers)


OMG! 12 fel!! Bäst att fixa dem ...



Men ända felet med första koden är att vi hade glömt andra argumentet (b), vilket är en ganska vanlig orsak till buggar. Felet kvarstår dock efter att vi fixat alla "fel" som Lintern hittade.

Här har du ett exempel på varför jag jämför med undefined:


Jag rekommenderar denna video: https://www.youtube.com/watch?v=wf-BqAjZb8M (Raymond Hettinger - Beyond PEP 8 -- Best practices for beautiful intelligible code - PyCon 2015)

Kanske dags att starta egen tråd om ECMAscript best practices?

Så vilken slutsats drar du från ovanstående inlägg och varför?

De hade varit bra. Om någon moderator vill bryta ut våra inlägg så vore de toppen. Är dock osäker på titeln då ämnet är ganska brett.

Glömde posta vad min linter säger.

Fick ett fel; indenteringen. Har kopplat cmd-ä till --fix i eslint så den fixar automatiskt till en majoritet av alla fel direkt i editorn. Använder Googles regler med 2 undantag och några extra regler. Har bl.a stängt av jsdoc.

Har du kollat vilka sponsorer Lets encrypt har?

För att få lite "peace of mind" så kan du titta närmare på deras sponsorer och deras senaste inlägg om Mozilla Root Certificate. Jag tror att Let's Encrypt kan bli en betydande spelare inom säkerhet när deras egna Root CA finns i de större webbläsarna osv.

Letsencrypt verkar rätt stabilt och kommer förhoppningsvis existera i flera år framöver.

Funderar dock på eventuella problem om man hårdlänkat adresser med httpS:// (S på slutet som i SSL/TSL) och Letsencrypt skulle stänga ner eller börja ta ordentligt betalt.