![\"Bluehost](\"https:\/\/www.likacloud.com\/wp-content\/uploads\/2025\/12\/20251231095917.webp\" "\\"\\"")
\r\n\t\t\t\t\t\t\t\t\t\r\n\t\t\t<\/div>\r\n\t\t\t\r\n\t\t\t\r\n\t\t\t![\"hosting.com](\"https:\/\/www.likacloud.com\/wp-content\/uploads\/2025\/12\/20251227070008.webp\" "\\"\\"")
\r\n\t\t\t\t\t\t\t\t\t\r\n\t\t\t<\/div>\r\n\t\t\t\r\n\t\t\t\r\n\t\t\tDV-Zertifikate eignen sich hervorragend f\u00fcr pers\u00f6nliche Webseiten, Blogs, Testumgebungen oder kleine Projekte, bei denen es nicht erforderlich ist, die Identit\u00e4t der Organisation anzuzeigen. Sie bieten eine gleiche Verschl\u00fcsselungsst\u00e4rke wie hochrangige Zertifikate, doch in der Adressleiste des Browsers wird lediglich ein Schlosssymbol sowie \u201chttps\u201d angezeigt \u2013 der Name des Unternehmens wird nicht dargestellt.<\/p>\n\n\n\n
Organisationsvalidierung Typenzertifikat<\/h3>\n\n\n\n
Organisatorisch verifizierte Zertifikate \u00fcberpr\u00fcfen nicht nur die Eigentumsrechte am Domainnamen, sondern auch die Echtheit der beantragenden Organisation. Die Zertifizierungsstelle (CA) pr\u00fcft die von der Antragstellerin\/dem Antragsteller eingereichten Unterlagen \u2013 beispielsweise die Firmenregistrierung \u2013 und kann diese gegebenenfalls auch telefonisch \u00fcberpr\u00fcfen. Dieser Prozess dauert in der Regel 2 bis 5 Arbeitstage.<\/p>\n\n\n\n
OV-Zertifikate enthalten den Namen der Organisation in den detaillierten Informationen des Zertifikats und verleihen den Website-Besuchern damit mehr Vertrauen. Sie eignen sich hervorragend f\u00fcr Gesch\u00e4ftswebseiten, Unternehmensportale sowie alle Online-Dienstleistungsanbieter, die ihren Nutzern ihre offizielle, legale Identit\u00e4t zeigen m\u00fcssen. OV-Zertifikate sind die bevorzugte Wahl, um ein vertrauensw\u00fcrdiges Image auf Unternehmensebene aufzubauen.<\/p>\n\n\n\n
Erweitertes Validierungszertifikat<\/h3>\n\n\n\n
Erweiterte, verifizierte Zertifikate z\u00e4hlen zu den strengsten Zertifizierungsarten und bieten den h\u00f6chsten Sicherheitsstandard sowie das gr\u00f6\u00dfte Vertrauensniveau. Neben allen Schritten der Organisationsermittlung f\u00fchrt der Zertifizierungsanbieter (CA) auch weitere, strengere \u00dcberpr\u00fcfungen durch, um sicherzustellen, dass die beantragende Organisation tats\u00e4chlich eine rechtm\u00e4\u00dfig existierende und gesetzlich anerkannte Einheit ist.<\/p>\n\n\n\n
Das auff\u00e4lligste Merkmal von EV-Zertifikaten ist, dass in Browsern, die EV-Zertifikate unterst\u00fctzen, nicht nur ein Schlosssymbol in der Adressleiste angezeigt wird, sondern auch der Name des verifizierten Unternehmens direkt in gr\u00fcner Farbe hervorgehoben oder besonders sichtbar dargestellt wird. Dies bietet in Branchen mit hohen Anforderungen an Vertrauensw\u00fcrdigkeit \u2013 wie Finanzen, Versicherung und E-Commerce \u2013 die deutlichste M\u00f6glichkeit, die Authentizit\u00e4t der betreffenden Website zu erkennen. Mit der Weiterentwicklung der Browseroberfl\u00e4chen werden jedoch einige Browser die gr\u00fcne Anzeige der Adressleiste f\u00fcr EV-Zertifikate nicht mehr hervorheben; dennoch bleiben die strengen Verifizierungsstandards weiterhin der Goldstandard f\u00fcr die \u00dcberpr\u00fcfung der Identit\u00e4t von Webseiten.<\/p>\n\n\n\n
Dar\u00fcber hinaus gibt es je nach Anzahl der abgedeckten Domainnamen verschiedene Arten von Zertifikaten: Einzel-Domain-Zertifikate, Mehr-Domain-Zertifikate und Wildcard-Zertifikate. Nutzer k\u00f6nnen entsprechend der Anzahl der Domainnamen, die sie sch\u00fctzen m\u00f6chten, das passende Zertifikat ausw\u00e4hlen.<\/p>\n\n\n\n
Das Funktionsprinzip des SSL\/TLS-Protokolls und der Handshake-Prozess<\/h2>\n\n\n\n
Das Hauptziel der SSL- sowie der nachfolgenden TLS-Protokolle besteht darin, sichere Kommunikationsverbindungen auf unsicheren Netzwerken (wie dem Internet) herzustellen. Dieser Prozess wird durch eine Reihe von Schritten erreicht, die als \u201cSSL\/TLS-Handshake\u201d bezeichnet werden. Dabei werden asymmetrische Verschl\u00fcsselungstechniken, symmetrische Verschl\u00fcsselungstechniken sowie digitale Signaturverfahren kombiniert, um sowohl Sicherheit als auch Effizienz zu gew\u00e4hrleisten.<\/p>\n\n\n\n
Der Handshake-Prozess beginnt damit, dass der Client eine Verbindung zum Server herstellt und eine \u201cClientHello\u201d-Nachricht sendet. Diese Nachricht enth\u00e4lt die von dem Client unterst\u00fctzten TLS-Versionen, eine Liste der verwendbaren Verschl\u00fcsselungsschemata sowie eine zuf\u00e4llig generierte Zahl.<\/p>\n\n\n
![\"SSL-Zertifikat](\"https:\/\/www.likacloud.com\/wp-content\/uploads\/2025\/12\/20251227020448.webp\" "\\"\\"")
\n \n ![\"SSL-Zertifikat](\"https:\/\/www.likacloud.com\/wp-content\/uploads\/2025\/12\/20251229052118.webp\" "\\"\\"")
\n <\/a>\n \n \n UltaHost besuchen <\/a>\n <\/div>\n <\/div>\n\n \n\n\n\n\n\n\nDer Server antwortet mit einer \u201cServerHello\u201d-Nachricht, w\u00e4hlt die TLS-Version sowie das Verschl\u00fcsselungsprotokoll aus, die von beiden Parteien unterst\u00fctzt werden, und sendet anschlie\u00dfend eine eigene zuf\u00e4llige Zahl. Danach \u00fcbermittelt der Server sein SSL-Zertifikat, das seinen \u00f6ffentlichen Schl\u00fcssel enth\u00e4lt. Um zu beweisen, dass er den privaten Schl\u00fcssel besitzt, der zum \u00f6ffentlichen Schl\u00fcssel im Zertifikat passt, f\u00fchrt der Server den \u201cSchl\u00fcsselaustausch\u201d durch. Bei einem RSA-Schl\u00fcsselaustausch generiert der Client einen \u201cPr\u00e4-Prim\u00e4r-Schl\u00fcssel\u201d, verschl\u00fcsselt diesen mit dem \u00f6ffentlichen Schl\u00fcssel des Servers und sendet ihn an den Server \u2013 nur der Server, der den entsprechenden privaten Schl\u00fcssel besitzt, kann diesen entschl\u00fcsseln. Bei dem moderneren ECDHE-Schl\u00fcsselaustausch sendet der Server einen tempor\u00e4ren \u00f6ffentlichen Schl\u00fcsselparameter, der mit seinem privaten Schl\u00fcssel signiert ist.<\/p>\n\n\n\n
Der Client \u00fcberpr\u00fcft das SSL-Zertifikat des Servers. Dabei wird gepr\u00fcft, ob das Zertifikat von einer vertrauensw\u00fcrdigen Zertifizierungsstelle (CA) ausgestellt wurde, ob das Zertifikat noch g\u00fcltig ist und ob der in dem Zertifikat angegebene Domainname mit dem zu besuchenden Domainname \u00fcbereinstimmt. Dieser Schritt ist entscheidend, um Man-in-the-Middle-Angriffe zu verhindern. Nach erfolgreicher \u00dcberpr\u00fcfung generieren Client und Server unabh\u00e4ngig voneinander denselben \u201cHauptschl\u00fcssel\u201d mithilfe der zuvor ausgetauschten Zufallszahlen sowie des vordefinierten Pr\u00e4-Hauptschl\u00fcssels.<\/p>\n\n\n\n
Die beiden Parteien generieren anhand des Hauptschl\u00fcssels den f\u00fcr die symmetrische Verschl\u00fcsselung erforderlichen Sitzungsschl\u00fcssel. Ab diesem Moment wird bei allen nachfolgenden Daten\u00fcbertragungen auf der Anwendungsebene dieser Sitzungsschl\u00fcssel zur Verschl\u00fcsselung und Dekodierung verwendet. Symmetrische Verschl\u00fcsselung ist viel schneller als asymmetrische Verschl\u00fcsselung und eignet sich daher hervorragend f\u00fcr die Verschl\u00fcsselung gro\u00dfer Datenmengen. Nach Abschluss des \u201eHandshakes\u201c wird der sichere Kommunikationskanal eingerichtet, und die verschl\u00fcsselten HTTP-Daten (d.h. HTTPS-Daten) beginnen mit der \u00dcbertragung.<\/p>\n\n\n\n
Prozess der Installation von Zertifikaten sowie bew\u00e4hrte Praktiken f\u00fcr eine sichere Bereitstellung<\/h2>\n\n\n\n
Die Installation und Konfiguration nach Erhalt des Zertifikats stellen den letzten und wichtigsten Schritt zur Gew\u00e4hrleistung der Sicherheit und Wirksamkeit dar. Der Prozess umfasst in der Regel die Erstellung einer Zertifikatsignaturanfrage, die Einreichung des CSR (Certificate Signing Request), die \u00dcberpr\u00fcfung der Anfrage, das Herunterladen des Zertifikats sowie die anschlie\u00dfende Installation und Bereitstellung des Zertifikats.<\/p>\n\n\n\n
Zun\u00e4chst m\u00fcssen Sie auf Ihrem Server ein Paar Schl\u00fcssel (\u00d6ffentlicher Schl\u00fcssel und Privater Schl\u00fcssel) sowie eine Zertifizierungsanfrage (Certificate Signing Request, CSR) erstellen. Die CSR enth\u00e4lt Informationen \u00fcber Ihre Organisation, die Domain sowie den \u00d6ffentlichen Schl\u00fcssel und wird mit Ihrem Privaten Schl\u00fcssel signiert. Sie m\u00fcssen diese CSR an die Zertifizierungsstelle senden, bei der Sie das Zertifikat erwerben m\u00f6chten.<\/p>\n\n\n\n
Die Zertifizierungsstelle (CA) f\u00fchrt je nach Art des von Ihnen gekauften Zertifikats (DV, OV, EV) den entsprechenden Verifizierungsprozess durch. Nach erfolgreicher Verifizierung verwendet die CA ihren privaten Schl\u00fcssel des Root-Zertifikats, um Ihr \u00f6ffentliches Schl\u00fcsselpaar sowie Ihre Identifikationsdaten zu signieren. Anschlie\u00dfend erstellt sie die endg\u00fcltige SSL-Zertifikatsdatei und stellt sie Ihnen zum Herunterladen zur Verf\u00fcgung.<\/p>\n\n\n\n
Die heruntergeladenen Zertifikatsdateien enthalten in der Regel Ihr Serverzertifikat sowie ein oder mehrere Zwischenzertifikate (\u201eIntermediate CA\u201c-Zertifikate). Sie m\u00fcssen diese Dateien zusammen mit der zuvor generierten Privatschl\u00fcsseldatei auf Ihrem Webserver-Softwarepaket (z. B. Nginx, Apache, IIS usw.) installieren. In den Konfigurationsdateien m\u00fcssen die Pfade zu den Zertifikatsketten-Dateien und der Privatschl\u00fcsseldatei korrekt angegeben werden, au\u00dferdem m\u00fcssen HTTP-Anfragen auf HTTPS umgeleitet werden.<\/p>\n\n\n\n
Best Practices f\u00fcr sichere Bereitstellung<\/h3>\n\n\n\n
Einfach nur das Zertifikat zu installieren reicht nicht aus \u2013 es ist wichtig, die besten Sicherheitsrichtlinien f\u00fcr die Bereitstellung einzuhalten, um den Schutzeffekt zu maximieren. Ihr Server-Privatschl\u00fcsseldatei muss als h\u00f6chst geheimes Material behandelt werden; strenge Zugriffsrechte m\u00fcssen festgelegt werden, um zu verhindern, dass sie in die H\u00e4nde Unbefugter gelangt.<\/p>\n\n\n\n
Stellen Sie immer eine vollst\u00e4ndige Zertifikatskette ein. F\u00fcgen Sie das Serverzertifikat sowie die Zwischenzertifikate der Zertifizierungsstelle (CA) in der richtigen Reihenfolge zusammen, um sicherzustellen, dass der Browser auf das von ihm vertraute Rootzertifikat zugreifen kann \u2013 dadurch wird ein Fehler wegen einer unvollst\u00e4ndigen Zertifikatskette vermieden. Aktivieren Sie die strenge HTTP-Sicherheits\u00fcbertragungsrichtlinie, um den Browser anzuweisen, Ihre Website nur \u00fcber HTTPS innerhalb einer bestimmten Zeit zu besuchen. Dadurch wird der Schutz vor SSL-Striping-Angriffen verbessert.<\/p>\n\n\n\n
\u00dcberpr\u00fcfen Sie regelm\u00e4\u00dfig die G\u00fcltigkeit der Zertifikate und stellen Sie Erinnerungen zum Verl\u00e4ngern mindestens 30 Tage im Voraus ein. Ein abgelaufenes Zertifikat verhindert den Zugriff auf die Website \u00fcber HTTPS und f\u00fchrt zu Sicherheitswarnungen, was die Verf\u00fcgbarkeit und das Ansehen der Website erheblich beeintr\u00e4chtigt. W\u00e4hlen Sie starke Verschl\u00fcsselungsschemata aus und deaktivieren Sie in der Serverkonfiguration unsichere, veraltete Protokolle (wie SSL 2.0\/3.0) sowie schwache Verschl\u00fcsselungsschemata (die RC4, DES oder exportierte Verschl\u00fcsselungsmethoden verwenden). Priorisieren Sie dabei die Verwendung der Protokolle TLS 1.2 oder TLS 1.3.<\/p>\n\n\n\n
Schlie\u00dflich sollten Sie regelm\u00e4\u00dfig Online-SSL-Pr\u00fcfwerkzeuge nutzen, um Ihre Website einer umfassenden Sicherheits\u00fcberpr\u00fcfung zu unterziehen. Diese Werkzeuge \u00fcberpr\u00fcfen die G\u00fcltigkeit der Zertifikate, die konfigurierten Protokolle und die St\u00e4rke der Verschl\u00fcsselungsschemata sowie das Vorhandensein bekannter Sicherheitsl\u00fccken, um Ihnen dabei zu helfen, den Sicherheitszustand Ihrer Website kontinuierlich zu gew\u00e4hrleisten.<\/p>\n\n\n\n
Zusammenfassungen<\/h2>\n\n\n\n
SSL-Zertifikate sind die Grundlage f\u00fcr den Aufbau eines vertrauensw\u00fcrdigen und sicheren Internetumfelds. Sie sch\u00fctzen die Privatsph\u00e4re der Nutzer, indem sie die Daten\u00fcbertragung verschl\u00fcsseln und die Identit\u00e4t der Server \u00fcberpr\u00fcfen, verhindern Netzwerkangriffe und steigern deutlich den Markenwert sowie die Platzierung der Webseiten in Suchmaschinen. Von DV-, OV- und EV-Zertifikaten mit unterschiedlichen \u00dcberpr\u00fcfungsstufen \u00fcber die komplexen TLS-Handshake-Protokolle dahinter \u2013 das Verst\u00e4ndnis dieser grundlegenden Aspekte ist die Voraussetzung f\u00fcr eine fundierte Auswahl. Der richtige Erwerb und die korrekte Installation der Zertifikate, insbesondere die Einhaltung von Sicherheitsrichtlinien wie dem Schutz der privaten Schl\u00fcssel, der Konfiguration der Zertifikatskette, der Aktivierung von HSTS sowie regelm\u00e4\u00dfigen \u00dcberpr\u00fcfungen, sind entscheidend, um die Sicherheitsvorteile von SSL-Zertifikaten optimal zu nutzen. Angesichts der zunehmend komplexen Netzwerkbedrohungen hat die korrekte Bereitstellung und Verwaltung von SSL-Zertifikaten zu einer unverzichtbaren F\u00e4higkeit und Verantwortung f\u00fcr alle Webseitenbetreiber geworden.<\/p>\n\n\n\n
FAQ H\u00e4ufig gestellte Fragen<\/h2>\n\n\n\nWas sind die Unterschiede bei der Anzeige von DV-, OV- und EV-Zertifikaten in einem Browser?<\/h3>\n\n\n\n
DV-Zertifikate zeigen in der Adressleiste des Browsers lediglich ein Schlosssymbol sowie die Kennzeichnung \u201chttps:\/\/\u201d. OV-Zertifikate enthalten in ihren Details verifizierte Informationen \u00fcber die zugeh\u00f6rige Organisation; die Darstellung in der Adressleiste \u00e4hnelt jedoch der von DV-Zertifikaten. EV-Zertifikate unterliegen der strengsten \u00dcberpr\u00fcfung: Fr\u00fcher wurde der Firmenname in den meisten Browsern in gr\u00fcner Farbe hervorgehoben. Obwohl die Benutzeroberfl\u00e4che einiger moderner Browser (z. B. Chrome) auf ein Schlosssymbol vereinheitlicht wurde, sind die verifizierten Informationen \u00fcber die Organisation in den Zertifikatsdetails weiterhin deutlich sichtbar. In einigen firmenorientierten Browsern sowie bestimmten Anwendungsszenarien kommt es weiterhin zu speziellen Anzeigem\u00f6glichkeiten.<\/p>\n\n\n\n
Kann ein SSL-Zertifikat mehrere Domainnamen oder Subdomainnamen sch\u00fctzen?<\/h3>\n\n\n\n
Ja, das h\u00e4ngt vom Typ des von Ihnen gekauften Zertifikats ab. Ein Zertifikat f\u00fcr einen einzelnen Domainnamen sch\u00fctzt nur einen vollst\u00e4ndig qualifizierten Domainnamen. Ein Zertifikat f\u00fcr mehrere Domainnamen erm\u00f6glicht es Ihnen, mehrere verschiedene Hauptdomainnamen oder Subdomainnamen in einem einzigen Zertifikat zu erfassen und zu sch\u00fctzen. Ein Wildcard-Zertifikat hingegen sch\u00fctzt einen Hauptdomainnamen sowie alle untergeordneten Subdomainnamen desselben Levels \u2013 zum Beispiel sch\u00fctzt *.example.com a.example.com, b.example.com usw., aber nicht untergeordnete Subdomainnamen (wie test.a.example.com) oder den Hauptdomainnamen selbst (dies erfordert in der Regel eine zus\u00e4tzliche Regelung).<\/p>\n\n\n\n
Warum zeigt der Browser nach der Installation eines SSL-Zertifikats immer noch \u201cunsicher\u201d an?<\/h3>\n\n\n\n
Es gibt in der Regel mehrere Gr\u00fcnde f\u00fcr dieses Warnsignal. Der h\u00e4ufigste Grund ist, dass auf der Website-Seite immer noch Ressourcen, die \u00fcber das HTTP-Protokoll abgerufen werden, verwendet werden \u2013 beispielsweise Bilder, JavaScript-Skripte oder CSS-Dateien. Der Browser betrachtet den Inhalt dieser Seite daher als nicht vollst\u00e4ndig sicher. Ein weiterer m\u00f6glicher Grund ist eine unvollst\u00e4ndige Konfiguration der Zertifikatskette; der Server sendet in diesem Fall das zentrale CA-Zertifikat (Intermediate CA Certificate) nicht korrekt. Zudem kann das auf dem Zertifikat angegebene Domainname nicht mit dem Domainname \u00fcbereinstimmen, das Sie tats\u00e4chlich aufrufen, das Zertifikat ist abgelaufen oder wurde zur\u00fcckgezogen. Auch eine zu alte oder unsichere TLS-Protokollversion sowie ein unsicheres Verschl\u00fcsselungspaket, die vom Server konfiguriert wurden, k\u00f6nnen zu diesem Warnsignal f\u00fchren.<\/p>\n\n\n\n
Wie lange ist die G\u00fcltigkeitsdauer eines SSL-Zertifikats und ist der Verl\u00e4ngerungsprozess kompliziert?<\/h3>\n\n\n\n
Gem\u00e4\u00df den Branchenstandards betr\u00e4gt die maximale G\u00fcltigkeitsdauer von SSL-Zertifikaten derzeit 1 Jahr. Diese Ma\u00dfnahme dient der Steigerung der Sicherheit und f\u00f6rdert einen h\u00e4ufigeren Schl\u00fcsselaustausch sowie die \u00dcberpr\u00fcfung der organisatorischen Angaben. Der Verl\u00e4ngerungsprozess ist in der Regel einfacher als die urspr\u00fcngliche Antragstellung. Sie k\u00f6nnen die Verl\u00e4ngerung des Zertifikats vor Ablauf dessen im Kontrollpanel Ihres Zertifizierungsanbieters initiieren; in der Regel wird das zuvor verwendete organisatorische Datenmaterial wiederverwendet. M\u00f6glicherweise m\u00fcssen Sie lediglich ein neues CSR (Certificate Signing Request) erstellen und die Domain\u00fcberpr\u00fcfung durchf\u00fchren. Es wird empfohlen, eine automatische Erinnerung f\u00fcr die Verl\u00e4ngerung einzurichten und die Verl\u00e4ngerung mindestens 30 Tage im Voraus durchzuf\u00fchren, um Ausf\u00e4lle der Website-Dienste aufgrund des Ablaufs des Zertifikats zu vermeiden.<\/p>","protected":false},"excerpt":{"rendered":"
SSL-Zertifikate sind digitale Dokumente, die die Sicherheit der Netzwerkkommunikation gew\u00e4hrleisten und den Datentransfer durch Verschl\u00fcsselung und Authentifizierung sch\u00fctzen. Der Artikel analysiert im Detail die Unterschiede und Auswahlkriterien der wichtigsten Zertifikatstypen wie DV, OV und EV und erl\u00e4utert das Funktionsprinzip und den Handshake-Prozess des SSL\/TLS-Protokolls. Au\u00dferdem werden die positiven Auswirkungen auf den Aufbau von Benutzervertrauen und die Suchmaschinenoptimierung (SEO) beschrieben.<\/p>","protected":false},"author":7,"featured_media":0,"template":"","meta":{"_acf_changed":false,"footnotes":""},"tags":[],"knowledge_category":[277],"class_list":["post-12376731","knowledge_post","type-knowledge_post","status-publish","hentry","knowledge_category-ssl-certificate"],"acf":{"site_seo_keywords":"SSL\u8bc1\u4e66,HTTPS,TLS\u63e1\u624b,\u8bc1\u4e66\u7c7b\u578b,\u7f51\u7ad9\u5b89\u5168,SEO\u4f18\u5316,OV\u8bc1\u4e66\u4e0eEV\u8bc1\u4e66\u533a\u522b"},"_links":{"self":[{"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/knowledge_posts\/12376731","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/knowledge_posts"}],"about":[{"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/types\/knowledge_post"}],"author":[{"embeddable":true,"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/users\/7"}],"version-history":[{"count":0,"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/knowledge_posts\/12376731\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/media?parent=12376731"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/tags?post=12376731"},{"taxonomy":"knowledge_category","embeddable":true,"href":"https:\/\/www.likacloud.com\/de\/wp-json\/wp\/v2\/knowledge_category?post=12376731"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}