Bekijk Volledige Versie : SSL wordt niet overschreven
Vandaag kreeg ik een mailtje van Google dat mijn shopping campagne on hold was gezet ivm beleidsschending.
Blijkt, het SSL certificaat zou niet goed zijn.
Afgelopen februari had ik nog een nieuwe aangeschaft en geinstalleerd.
Na een check blijkt inderdaad dat het certificaat niet juist zou zijn.
De info die terug komt:
Het gevonden SSL Certificate voor deze site is niet bedoeld voor xxx-xxxx.nl, waarschijnlijk is dit een andere website op één en dezelfde server.
Nu zie ik ook dat het oude certificaat is geinstalleerd :(
Wat ik ook doe ik krijg het nieuwe certificaat niet actief.
Wat heb ik gedaan:
SSL uitgezet in DirectAdmin.
VPS gereset.
SSL opnieuw geinstalleerd volgens de juiste handleiding, krijg hierbij ook geen foutmeldingen.
SSL weer aangezet.
SNI staat aan anders hadden de andere site's op de VPS ook een probleem gehad.
Symbolic link in DirectAdmin staat ook aan.
Hoe kan ik in DirectAdmin nou zorgen dat het nieuwe certificaat actief wordt?
WilliamAdams
10/05/17, 16:57
Kun je hier iets mee?
Apache will always use certificate of the first secure domain bound to a given IP address. If you take a look at /usr/local/directadmin/data/users/USERNAME/httpd.conf file, you will see something like:
...
<VirtualHost 192.168.1.1:443>
SSLEngine on
SSLCertificateFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.cert
SSLCertificateKeyFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.key
ServerName www.example1.com
...
<VirtualHost 192.168.1.1:443>
SSLEngine on
SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key
ServerName www.example2.com
...
In this example, the correct certificate is used.
If the 2nd VirtualHost section comes as 1st in your config file, the default server certificate is used instead for all domains bound to this IP address.
Apparently, changing default domain somehow caused reordering of VirtualHost sections. I am glad it worked for you, but it isn't a documented feature and might not work in other DA releases.
You should be able to fix this problem in any DA release by disabling SSL for all domains bound to this IP address except the one you have SSL certificate for.
stefantriep
10/05/17, 16:57
Dit had ik ook een keer, heeft te maken met legen cache van ssl/apache, zoek daar even op.
Bijvoorbeeld: http://stackoverflow.com/questions/34479227/ssl-renew-certificate-on-apache-keeps-using-old-certtificate-file
Dit had ik ook een keer, heeft te maken met legen cache van ssl/apache, zoek daar even op.
Bijvoorbeeld: http://stackoverflow.com/questions/34479227/ssl-renew-certificate-on-apache-keeps-using-old-certtificate-file
Ik het het SSL cache en apache cache leeg gemaakt volgens een handleiding die ik heb gevonden.
Het vreemde is dat de SSL nu wel juist werkt op de site, kreeg eerder een foutmelding dat deze niet juist zou zijn.
Het rare is dat de melding Het gevonden SSL Certificate voor deze site is niet bedoeld blijft staan.
Ik heb ook een heruitgifte van het certificaat aangevraagd en opnieuw geinstalleerd, helaas mag ook dat niets oplossen.
Zou het helpen als ik gewoon een geheel nieuw certificaat aanvraag en deze installeer?
stefantriep
10/05/17, 17:53
Het rare is dat de melding Het gevonden SSL Certificate voor deze site is niet bedoeld blijft staan.
Kan je mij in een PB de domeinnaam sturen zodat ik dit even kan checken? Anders kan ik je niet helpen.
Krijg nou de hik.....
Nu snap ik er helemaal niks meer van.
De ene check site geeft aan dat het certificaat niet juist is, de startdatum is van 2016.
De andere check site geeft aan het certificaat wel juist is, de startdatum is 2017........
Wat moet ik nou aanhouden?
stefantriep
10/05/17, 21:30
Ik zie 2 certificaten die de server aanbiedt, het standaard DirectAdmin certificaat en je gekochte certificaat. Kijk even naar de opmerking van William hierboven
Kun je hier iets mee?
volgens mij is dat alleen als SNI niet gebruikt wordt
nayonowe als je wil dan kan ik het even (kosteloos) voor je onderzoeken, met de juiste server toegang is het probleem eenvoudig te achterhalen
Als ik ga kijken naar het bestand dan zie ik dit staan:
SSLEngine on
SSLCertificateFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.cert
SSLCertificateKeyFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.key
SSLCertificateKeyFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.cacert
ServerName www.example1.com
De example en username staan natuurlijk wel correct vermeld.
Ik zie het maar 1 maal staan en geen 2x.
Moet ik dan die andere verwijzing toevoegen?
volgens mij is dat alleen als SNI niet gebruikt wordt
nayonowe als je wil dan kan ik het even (kosteloos) voor je onderzoeken, met de juiste server toegang is het probleem eenvoudig te achterhalen
SNI dient in mijn geval wel aan te staan anders krijg ik een conflict met het toevoegen van meerdere certificaten.
stefantriep
10/05/17, 23:10
Als ik ga kijken naar het bestand dan zie ik dit staan:
SSLEngine on
SSLCertificateFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.cert
SSLCertificateKeyFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.key
SSLCertificateKeyFile /usr/local/directadmin/data/users/USERNAME/domains/example1.com.cacert
ServerName www.example1.com
De example en username staan natuurlijk wel correct vermeld.
Ik zie het maar 1 maal staan en geen 2x.
Moet ik dan die andere verwijzing toevoegen?
Als dit er 1 maal staat per (sub)domeinis het goed, ligt het niet aan je user configs voor httpd.
Heb je bij SSL certificates in DirectAdmin het bolletje staan bij Paste a pre-generated certificate and key?
Zie je daar staan -----BEGIN PRIVATE KEY----- en -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- en onderaan in dat veld dit -----END CERTIFICATE-----
Hoeveel certificaten zie je staan bij Click Here to paste a CA Root Certificate?
Als dit er 1 maal staat per (sub)domeinis het goed, ligt het niet aan je user configs voor httpd.
Heb je bij SSL certificates in DirectAdmin het bolletje staan bij Paste a pre-generated certificate and key?
Zie je daar staan -----BEGIN PRIVATE KEY----- en -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- en onderaan in dat veld dit -----END CERTIFICATE-----
Hoeveel certificaten zie je staan bij Click Here to paste a CA Root Certificate?
Het staat er echt maar 1 maal in de httpd.conf.
Dat bolletje bij Paste a pre-generated certificate and key staat goed, meerdere malen gecontroleerd.
-----BEGIN PRIVATE KEY----- en -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- en onderaan in dat veld dit -----END CERTIFICATE-----
Staat er ook in met daarin netjes de key en het certificaat (ook in de juiste volgorde).
Het CA root certificate (met een vinkje bij Use a CA Cert.) staat ook netjes ingevuld.
verder staat er nog:
Certificate Hosts xxx.nl, www.xxxx.nl
Certificate Expiry Feb 7 23:59:59 2018 GMT
waarbij xxx.nl en www.xxx.nl mijn domeinnaam is.
Alles lijkt ook echt goed te staan.
Ramon Fincken
11/05/17, 07:43
Waarom huur je geen systeembeheer in om t goed na te lopen ipv zelf te zoeken?
Ik heb er geen problemen mee om iemand in te huren, ik was echter van mening dat het een kleine instelling in DirectAdmin zou zijn.
Dit soort kleine dingetjes moet je toch ook even snel zelf kunnen proberen op te lossen?
Daarnaast wil ik graag weten wat het probleem is, komt er een volgend nieuw SSL certificaat dan komen de problemen misschien weer naar voren.
Ramon Fincken
11/05/17, 09:37
het feit dat je het alsnog niet nu snel kunt oplossen zou een teken kunnen zijn dat je iemand het laat doen.
en met je opmerking in je 2e alinea zou ik dan gewoon aan die sysadmin vragen wat het probleem was, hoe het is opgelost en hoe het te voorkomen is. Dat lijken me hele normale vragen voor iemand die je inhuurt voor een probleem als dit.
zeker gezien het feit dat je geld stopt in die specifieke site en/of er ook geld mee verdient ..
Ik heb inmiddels de vraag bij iemand neergelegd of er hulp kan worden geboden.
Mocht dit niet het geval zijn zal ik zeer zeker een hulp aanvraag plaatsen op het board.
Te lang zelf blijven klungelen kost meer dan een persoon even inhuren!
WilliamAdams
11/05/17, 16:24
En, ben je al wat verder?
Het probleem is verholpen!
Ik heb hulp gehad van T.Bloo.
Hij heeft alles nagekeken en een aanpassing gemaakt in de instellingen voor de SSL.
Zeer fijn dat er veel en goede hulp geboden wordt!
WilliamAdams
11/05/17, 16:35
Kijk dat zijn mooie berichten. Hulde aan t.bloo, wat was er nu eigenlijk precies mis dan? t.bloo?
Ik heb de instellingen eerst gecontroleerd en die waren wat mij betreft in orde. Maar er zijn SSL check sites die blijkbaar ook het certificaat van het kale IP adres opvragen. En daar staat standaard een self signed certificaat. Ik heb daar het certificaat van de hoofdwebsite neergezet.
Maar eigenlijk denk ik dat Google naar het IPv6 adres kijkt en dat lijkt me niet goed geconfigureerd (verder niets aan gedaan) en dus kreeg die daar het self signed certificaat.
Ik heb de instellingen eerst gecontroleerd en die waren wat mij betreft in orde. Maar er zijn SSL check sites die blijkbaar ook het certificaat van het kale IP adres opvragen. En daar staat standaard een self signed certificaat. Ik heb daar het certificaat van de hoofdwebsite neergezet.
Maar eigenlijk denk ik dat Google naar het IPv6 adres kijkt en dat lijkt me niet goed geconfigureerd (verder niets aan gedaan) en dus kreeg die daar het self signed certificaat.
Nogmaals zeer hartelijk bedankt voor de hulp!!
Het SSL probleem is zeer netjes opgelost.
Het gedeelte met het IPV6 heb ik al een keer eerder gehad, een vaste klant tipte mij destijds dat de website alleen aangaf "apache is functioning normally"
Ik heb toen op aanraden het AAAA record verwijderd waarna het probleem was opgelost.
Nu was er weer een AAAA record actief, waarom???
Ik heb het verwijderd en nu hoop ik morgen via een check te zien dat IPV6 automatisch weer wordt omgezet naar IPV4.