Es gibt verschiedene Möglichkeiten. Ein Wildcard Zertifikat ist recht teuer, aber durchaus eine (vor allem einfache!) Möglichkeit.
Eine andere Möglichkeit (wenn das technisch für dich in Frage kommt) wäre ein Reverse Proxy. Eine Domain und ein SSL-Zertifikat genügt und du könntest die Kundenserver über einen zentralen Proxy ansprechbar machen.
Deine URLs würden wie folgt aussehen:
http://www.example.com/kundeA
http://www.example.com/kundeB
Dein Reverse Proxy würde Anfragen an /kundeA dann an den entsprechenden Server des Kunden A weiterleiten. Bedeutet natürlich, dass die Pfade sich ändern. Also eine beispielhafte Anfrage an /kundeA/delete/1234 würde beim Kundenserver an /delete/1234 weitergeleitet.
Das ist deutlich komplexer, aber auch deutlich billiger. Nur damit du auch eine Alternative zu Wildcard kennst.
Um eine sinnvolle Möglichkeit zu nennen, wären ein paar mehr Infos aber praktisch. Eventuell könnte auch ein Zertifikat pro Kunde eine Möglichkeit sein. Diese könntest du den Kunden in Rechnung stellen. Man muss eben ausrechnen, ab wann sich Wildcards lohnen.
Noch was anderes: Wenn du Kundenserver per HTTPS erreichbar machen willst, dann handelt es sich vermutlich um Webseiten (sprich:
HTML) die ausgeliefert werden und von
normalen Browsern aufgerufen werden? Denn es gibt nachwievor die Option Zertifikate nicht von einer CA zu kaufen, sondern eine eigene CA anzulegen und die Zertifikate von dieser unterschreiben zu lassen.
Entgegen allgemeiner Meinung ist das dann nicht weniger sicher, sondern bei richtiger Konfiguration sogar sicherer. Wenn du der Clientsoftware nur deine CA mitgeben kannst, dann ist auch nur deine CA dazu berechtigt, Zertifikate für deine Server auszustellen. Bei Browsern hingegen sind hunderte CAs hinterlegt und jede davon kann prinzipiell Zertifikate aussstellen, die dann akzeptiert werden. Ist auch nur eine der hunderten CAs nicht sicher, fällt die Sicherheit des gesamten Systems.