En af grundene til ikke at have instansens IP-adresse i servercertifikatets fællesnavn er, at disse IP'er kan ændre sig. Hvad er IP-adressen på instans A i dag, kan være IP-adressen på instans B i morgen, fordi A blev slettet, eller A besluttede at den ikke vil have IP-adressen længere. Så instansnavnet blev besluttet som værende en mere unik identifikation af instansen.
Desuden har mysql-klientbibliotekerne som standard værtsnavnsbekræftelse deaktiveret. http://dev.mysql.com/doc/refman /5.7/da/ssl-options.html
Med hensyn til MITM-angreb er det ikke muligt at MITM angriber en Cloud SQL-instans, fordi servercertifikatet og hvert af klientcertifikaterne er signeret af unikke selvsignerede CA'er, som aldrig bruges til at signere mere end ét certifikat. Serveren har kun tillid til certifikater, der er underskrevet af en af disse CA'er. Årsagen til at bruge unikke CA'er pr. klientcertifikat var, at MySQL 5.5 ikke understøttede lister med tilbagekaldelse af certifikater, og vi ønskede heller ikke at håndtere CRL'er, men ønskede at understøtte sletning af klientcertifikater.
Vi vil undersøge måder at understøtte SSL for klienter, som ikke kan slå værtsnavnvalidering fra. Men jeg kan ikke love en ETA på dette.
Cloud SQL Team.