Swish API, klientcertifikat & Amazon Linux (EBS) (NSS)
På jobbet håller vi på att migrera till Amazons infrastruktur från de virtualiserade VMWare-instanserna med Debian vi kör idag. På Amazon har vi valt en uppsättning med Amazon Linux (PHP) som körs i “Elastic Beanstalk”. Målet med migreringen är att få bort så mycket manuellt underhåll som möjligt, öka driftsäkerheten och få en miljö som skalar av sig själv.
Amazons Linuxversion bygger på CentOS / Redhat / RPM av pakethanteringssystem och struktur att döma. Deras curl är kompilerat mot Mozillas NSS istället för OpenSSL. I Swish e-handelslösning som vi använder så autentiserar man mot deras API med hjälp av klientcertifikat, något ganska ovanligt för betallösningar riktade mot e-handel.
Fick en massa problem med att SSL-handskaken inte fungerade, curl spottade ut felmeddelande på felmeddelande. Här var PHP-koden som användes. Fungerar felfritt med curl & openssl:
Efter en massa felsökning så misstänkte jag att NSS var boven i dramat. Visade sig att man var tvungen att lägga till Swish certifikat i NSS certifkikatdb. Det fungerade alltså inte att skicka med certfikaten som ovan.
a) Skapa en pksc12-fil från din private key och Swish-certet:
b) Importera deras CA-cert.
c) Importera Swish-certet vi skapade i steg “a”
Nu får vi istället i CURL använda oss av certifikatets namn i nssdb. Det hittar vi genom att köra följande:
Så vi får anpassa PHP-koden:
Sen kommer nästa problem: inget är persistent i en EBS-miljö. Miljön “nollas” ju ibland, så vi får se till att köra allt när en ny instans startas med hjälp av .ebextensions:
.ebextensions/03-certificate-files.config
Lägger till våra certifikat-filer.
.ebextensions/04-generate-pkcs12-and-add-to-nssdb.config
Genererar pkcs12-filen från certifikaten vi behöver och lägger till Swish CA-cert och vårt cert i nssdbn. Sen städar upp! Finns ingen anledning för dem att ligga kvar.