SSL Labs DROWN Test Implementation Details

Two days ago the DROWN vulnerability came to light, showing new ways to attack TLS. SSL Labs deployed tests for DROWN in the staging environment yesterday, and we’ll be pushing it to production shortly. Because DROWN is a tricky problem, the aim of this blog post is to provide an explanation of what we test for and how exactly.

First of all, we have known SSL v2 to be insecure for a very long time—over 20 years. As a result, even before DROWN SSL Labs used to give Fs to servers that supported this ancient version of the SSL protocol. DROWN actually makes things worse, because it abuses SSL v2 to attack all other protocols.

Further, DROWN introduces two additional attack vectors:

A server that has SSL v2 enabled can be used to attack any other servers that reuse the same RSA key; even those servers that don’t themselves support SSL v2. This attack is generic (CVE-2016-0800) and affects any protocol implementation.

A server that has SSL v2 enabled and is also running a special vulnerable version of OpenSSL (CVE-2016-0703) can be used to attack all other hostnames appear in its certificate.

For the above reasons, the security of a server can’t be determined only by looking at its configuration. For DROWN, we have to look for the presence of the server’s RSA keys and/or certificate hostnames elsewhere. As you can imagine, this can be tricky. However, this is where the DROWN authors and Censys come in: they have exposed an API that SSL Labs now uses to find vulnerable servers in their data set.

Because the data we’re getting from Censys can be potentially stale, in SSL Labs we perform real-time checks for any of the above conditions. If we can find one matching server elsewhere, we consider the server being tested to be vulnerable and give it an F. Please note that the first 4 columns of the results (IP Address, Port, Export and Special) come from the search engine and could be outdated. The last column (Status) comes from SSL Labs; it reflects the current situation.

One final thing: if you’re manually checking the SSL Labs results, please don’t get confused if you’re unable to connect to a host using SSL v2. If SSL Labs is still showing the host as vulnerable, chances are it’s using a version of OpenSSL that can complete a handshake even when no cipher suites are configured (CVE-2015-3197). SSL Labs checks for this variant as part of its testing.

Related

84 responses to “SSL Labs DROWN Test Implementation Details”

If a mailserver uses a version of OpenSSL that “can complete a handshake even when no cipher suites are configured”, and all SSLv2-ciphers are disabled, does the mailserver still cause other servers that use the same SSL-certificate to be vulnerable to DROWN?

If there’s SSLv2 running on some server, that server can be used to attack any other server that uses the same RSA key or in some cases has the same hostnames in the certificate. The target servers don’t need to run SSLv2.

i am using following cipher but my site is still having F due to to drown issue. Its HAPROXY server
ind 111.111.111.111:443 ssl crt /etc/ssl/certs/tsasafety.com.pem ciphers AES128+EECDH:AES128+EDH no-sslv3 no-tls-tickets force-tlsv12 no-tlsv11 no-tlsv1

please assist me. what should i do? as per haproxy 1.5 documentation sslv2 is disabled by default

I am guessing that there is some _other_ server with SSLv2 enabled. If you look in the DROWN section, it contains the list of IP addresses where SSL Labs detected SSLv2. Disable this protocol version there and the F grade will go away.

Question is following:
We have site with IB which uses EV certificate with domain konet.kovanica.hr, and we have wildcard chertificate *.kovanica.hr which is used on 2 other servers on internet.
One of that server has enabled SSL2/SSL4 because of compatibility issues with some software, and as a consequence, based on your tests, our internet banking is vurnable?
I don’t understand how can vurnability on one server be exploted on another with completly different certificate which has different private key?
Can You please explain it?

I think that is why I am getting DROWN results as well. From what I understand, if you have 2 servers using one Wildcard, and one is running SSLv2, then the attacker can use the attack on the SSLv2 to break even TLS 1.2 on the secured server. Is this the case?

No, this is not my case.
I have internet banking site which uses “EV certificate” with only one domain “konet.kovanica.hr”, and in addition second certificate which is “wildcard certificate” “*.kovanica.hr” used on other servers, not on internet banking site.konet.kovanica.hr, but it is not used on that server.

server A has SSL2/SSL3 enabled due to compatibility issues.
server B has only TLS enabled
server C has only TLS enabled

I understand that server A and B are vurnable due both share same certificate,
but I DON’T UNDERSTAND how server C can be vurnable in that configuration, because it has totaly different certificate which uses different private key therefore stolen “session” from server A can’t be used on server C.

I think that Drown Attack test is wrong (in my case/configuration), because domain name in the certificate is not part of key exchange and it’s not relevant for vulnerability.
Servers can be affected only if they have same public key (private key), but if you have different keys, different certificates on two different servers (even if both include SANs which covers both servers) vulnerability of one can’t affect another.

The problem is that the wildcard certificate for server “*.kovanica.hr” can be used in a man-in-the-middle attack by impersonating also “konet.kovanica.hr”.

This happens with all wildcard certificates, e.g. all subdomains of a wildcard are affected; “secure.konet.kovanica.hr” would not be affected as that is not covered by the wildcard certificate. That is why this is quite tricky and a huge issue.

I have to say that I have a limited knowledge of SSL protocols and PKI, but even with this what you are saying that it doesn’t matter if attacker have a private key, for me is something what is at least strange.
I don’t say that You are not right, but instead of that, I’m really curious and I would really want to know how someone can “take” certificate from vulnerable servera and put himelf in a middle and decrypt data without a private key?
I understand that attacker can make simmilar site and use public part of key to impersonate himself as origin site, but I don’t understand how he can decrypt receiving content?
My question is even now after server is affected if I close SSL2/3 do I need to recertificate server, reissue with another key or it’s enought just to close SSL2/3 protocol?

> I have to say that I have a limited knowledge of SSL protocols and PKI, but even with this what you are
> saying that it doesn’t matter if attacker have a private key, for me is something what is at least strange.

it does not matter that he does not have the specific private key for the specific certificate if he can access the private key for the wildcard-certificate that also covers the more specific sub-domain.

If I can get my hands on the private key of the wilcard certificate “*.kovanica.hr” it is trivial to set up a server (webserver, proxy etc. you name it) that can impersonate also “konet.kovanica.hr”. If I now manage to manipulate the DNS or perform a man-in-the-middle-attack on a customers connection towards your server, the server will show no certificate error, as my certificate is trusted and correct:

Customer Man-in-the-Middle konet.kovanica.hr

(this is simplified but shows the problem).

Man-in-the-middle can use the wildcard certificate without raising any problems regarding the certificate.

The problem is that the wildcard certificate for server can be used in a man-in-the-middle attack by impersonating also “konet.kovanica.hr”.

> I don’t say that You are not right, but instead of that, I’m really curious and I would really want to know
> how someone can “take” certificate from vulnerable servera and put himelf in a middle and decrypt data
> without a private key?

he uses the private key, just the private key of the wildcard certificate.

> I understand that attacker can make simmilar site and use public part of key to impersonate himself as
> origin site, but I don’t understand how he can decrypt receiving content?

while it is correct that only getting your hands on the private key would not be sufficient in a DH-world to decrypt a snippet of a communication, but by using a man-in-the-middle attack he can by decrypting and re-encrypting contents “live” in between servers. At least that is my understanding. The customer would be talking to the man-in-the-middle (heck, the certificate is correct, trusted and signed by a CA!) who would decrypt, do whatever he wants with the data and then forward it to the real destination server.

> My question is even now after server is affected if I close SSL2/3 do I need to recertificate server, reissue
> with another key or it’s enought just to close SSL2/3 protocol?

my understanding is that you need to first close the SSL2-protocol on the other servers and then reissue the wildcard certificate with a new private key. Your non-wildcard certicate should not be compromised by this; also the old wildcard should be revoced etc. so that it can no longer be used (to impersonate etc.).

@Mario Spicar: just to make myself clear (some “*” stars were removed from my previous comments), the communication that happens between your server konet.kovanica.hr and the customer without a man-in-the-middle is still secure. So even if I am able to sniff at that communication I would not be able to decrypt it (DH or not) easely.

What is problematic is that I can use the wildcard certificate with the private key (found on the vulnerable servers with SSLv2 enabled) to impersonate also “konet.kovanica.hr” in a man-in-the-middle attack. In that case the communication does not happen “directly” between your server and the customer, but between the customer and the “man-in-the-middle” server and the “man-in-the-middle” server and your server. From a certificate point of view both connections would be viewed as trusted and not compromised, while the man-in-the-middle could listen to all communication, access the private data, do whatever he wants with it including forwarding it re-encrypted to your server. This is possible with the private key of the wildcard (I do not need the private key of your more specific certificate) and in part also due to the fact this attack works in realtime. In my man-in-the-middle attack scenario above there are two SSL-connections: (1) customer MitM-server and (2) MitM-server your server (and yes, it is a simplified scenario).

The situation with a wildcard certificate is quite similar to that of a rogue Certification Authority: no warning would be shown in the browser about the certificate not being trustworthy and the connection would be deemed secure and trusted from a certificate point-of-view, while it is not even if it is running TLS.

You make an incorrect assumption when you say that the specific name isn’t vulnerable. If *.domain.tld is vulnerable, then by breaking the *. private key I can perform a fully-trusted-man-in-the-middle (where my man in the middle is using a valid and trusted cert, signed by YOUR chosen CA) on EVERY more-specific subdomain of domain.tld.

Wildcard certificates are particularly dangerous this way. If I can compromise your wildcard certificate for *.domain.tld but you have a great TLS 2.0 only implementation and specific certificate for sub1.domain.tld; it doesn’t matter. Since I broke *.domain.tld then the wildcard pattern also matches sub1.domain.tld so I have the ability to man-in-the-middle sub1.domain.tld without ever being able to break that certificate. All I had to do is break your wildcard.

This is also why security guys 1) greatly dislike wildcard certificates (or wildcard anything, for that matter) and 2) try to ensure that anything using a wildcard certificate is among the most secured of your servers (while as a server admin, I used to treat a wildcard as the junk cert that went on the transient boxes because of how short their life span, regardless of the poor implementation of a web server or SSL that I was using them with).

Responding to the requests to explain why DROWN affects servers that don’t (or never had) SSL v2 enabled: The issue is that of contamination, which happens if either 1) an RSA key from one server is used on another server that has SSL v2 enabled (the first server doesn’t have to have it) or 2) a certificate that is used on a server with SSL v2 and CVE-2016-0703 is valid for some other name/server.

I see that this latter variant is creating lots of confusion. You can read the full explanation in the DROWN paper, but the crux is this: Because CVE-2016-0703 makes this attack possible in real-time, the attacker can take the certificate from the vulnerable server and attack any other server where the certificate matches. The attacker doesn’t need the corresponding private key, and the key doesn’t even need to be the same as on the target server. I repeat, the keys don’t need to be the same :)

yes, but – please correct me if I am wrong – in scenario 2 the attacker can not decrypt a snippet of eavesdropped communication, he can only participate in an active man-in-the-middle attack towards a server without SSLv2 enabled that has a different private key (the padding oracle based on SSLv2 is an oracle only for that particular private key; nonetheless if the certificate is valid for some other name or server an MitM-attack is possible using the certificate from the vulnerable server).

We have 2 wildcard certificates for the same subject, the older one with a SHA1 signature and the newer one with a SHA256 signature. One of our server is configured using the older certificate and unfortunatelly SSLv2 is enabled, other servers are configured using the newer certificate and SSLv2 is disabled.

Question: From my opinion only the server with the older certificate can be attack by DROWN, right?

Both servers can be “attacked” in the sense that an active man-in-the-middle attack is possible; but after disabling SSLv2 you would only need to reissue the certificate from the server that had SSLv2 enabled by using a new key! Of course if you use the same private key on both servers you need to reissue both.

REMEMBER :: After removing SSLv2 you still need to re-issue your certificate with a new private key, revoking the old cert/key as compromised, in order to fix the security vulnerability. Otherwise an attacker could already have a compromised copy of your private key and continue to use it even though you no longer use SSLv2.

But revoking the old cert (as compromised, so it shows in revocation lists) and using a fresh new key will finish the fix to the issue.

If you scroll down toward the end of your SSL Labs report, under “Protocol Details” where we report the DROWN findings, the IP address of the vulnerable server will be listed. If you disable SSLv2 on that server the F grade should go away.

Ivan,
I believe I’m seeing false positives from this experimental DROWN test, that is marking our formerly grade “A” sites as grade “F”. The ssllabs report correctly shows v2 disabled, and the same cert/keys are not used anywhere else where v2 might be enabled.

I suspect the parsing of the drownattack test data is being done incorrectly.
I don’t see these particular hosts on either drownattack or censys pages as having problems; the IPs listed as being vulnerable in the “Drown” section of the report are in our domain but do not share keys or certificates with the hosts being marked “F”. Since it’s not the same certificate (nor same system nor keys), the matching hostname (a wildcard) shouldn’t be enough to label my separate systems as vulnerable.

Just to clarify (there seems to be a limit to the response depth, which is why I am responding to my own comment): a wildcard certificate on another server that supports SSL v2 is enough to make you vulnerable to DROWN. In other words: the certificates don’t have to be the same; having the same hostname coverage is sufficient.

gruene-mol.de is a web server using a Let’s encrypt cert, located in a physically different hosting environment.
mail.gruenes-cms.de is a mail server using a wildcard, which is not relevant because it isn’t even valid from mail.gruene-mol.de. clients also don’t connect directly to the server using mail.gruene-mol.de (they don’t use port 25, but 465)

So the root cause here is that 5.9.53.154 supports SSLv2 on port 25. We verified this manually. If this is fixed, your grade will improve (assuming no other servers are found with the same key). FYI, the reused key is not the main key, but the one obtained from gruene-mol.de when SNI is not used.

I have a vendor’s website which shows here to be vulnerable to DROWN attacks, but they claim that SSL2 is wholesale disabled, immunizing them to this issue – if SSL Labs reports the URL as vulnerable, is it rock-solid that the vendor is incorrect, or do I need to do additional testing?

[Replying to myself because I am not able to reply to the original post.]

@JC Denton, show them the report. At the bottom, the IP addresses with SSL v2 will be shown. In some cases you can test that IP address yourself, but there’s at least one case in which you’d need a special tool to force the a particular SSL v2 where no suites are configured (but they’re still accepted).

Hi Ivan,
You seem to be one of the few experts answering questions about the DROWN vulnerability. I am NOT a security guy. I’m a PC & LAN support tech and tend to follow best practices in an attempt to provide my customers with reasonable security, but the vulnerability has me not sure about several issues that I’m hoping you will address:

Our office practice management software lives on a local Windows Server 2008r2 box. It is web accessible through IIS WITHOUT a DMZ. (i.e. the public IP port 443 is forwarded directly to our primary server… yes, I know this is bad practice). I fought against this implementation due to this being contrary to best practices, but due to industry requirements and our practice management vendor having limited implementation options, we have it setup this way. I have all SSL protocols disabled, all RC4 ciphers disabled, but otherwise, a canned Windows Server 2008 R2 IIS implementation. The vendor provides an SSL certificate through RapidSSL and the root domain for us to connect externally to our server through a sub-domain for each of their clients. I didn’t realize this until I did the drown check, but the DROWN check pulled up the IP addresses for all of this vendor’s clients running this practice management software and our 2nd office. Out of 27 IP addresses shown from the DROWN check, our two offices are the only ones with SSL disabled. Questions:
1) What is my exposure?
2) Can someone utilize certificates that have been broken on one of these other servers to access my server/attack my server/read my server’s data/perform any malicious action toward my server?
3) The blogs all mention “if the same key” is used. How can I determine if my servers are using the same key as some of these other servers linked to us through the vendors RAPIDSSL certificate?
4) Some of these other servers have port 3389 directly open, so they are at risk for someone having direct remote access to them if they are hacked. Does this leave me open to a MITM scenario?
5) If I create an access control list blocking access from these other servers to my server, would that provide any benefit or am I wasting my time with that avenue?
6) If we were to purchase our own certificate and use that for our IIS access, would that remove any threat that these other insecurely configured servers pose to us?
7) Is there anything else I should know in this listed scenario keeping in mind that I have no control over the vendor’s certificate, domain, and have limited ability to modify this weak configuration?

Thanks for taking the time to answer questions about this for those of us who just don’t understand this level of certificates, security, and such.

Jeff, I am sorry that I can’t respond to your comment in great detail, but I will try some advice.

3 – the SSL Labs report for your site will tell you if your RSA key is available elswhere with SSLv2. If that’s the case, generating a new private key (and of course certificate) will address DROWN for you.

6 – yes, except in the case that your server’s hostname is also used by some other servers that have SSLv2 enabled. But your SSL Labs report should tell you if that’s the case.

Hi Ivan and thanks for the info. It’s weird, but I can’t hit reply on your message for some reason. That is great information and helps quite a bit. I was hoping that you’d give me everything on a silver plate, but no such luck. I’m so ignorant about certificates that I’m not even sure what I have to do to generate a new private key, but I assume since our software vendor owns the certificate I’d have to go through them, so I’ll be making a call tomorrow. If they can’t or won’t give me a certificate and private key for my servers that is separate from these other servers, I will explore getting a certificate of our own. Can you recommend any basic (and hopefully free) reading that I can find so I can get a better idea of how to work with certificates and get a better understanding?

SSL Labs test too for DROWN is a terrific resource, but I am beginning to suspect that it is not incorporating updates from Censys in a timely fashion.

Case in point, I fixed a DROWN issue on one particular host over a week ago, but SSL Labs still reports the site as failing. In this particular case, the host was using a wildcard certificate. The same wildcard cert is used on several other systems that are still running deprecated versions of SSL.

The fix, in this case, was to replace the wildcard cert on the host we are working on with a unique cert. Censys scans picked up the new certificate on Friday, April 29th. SSL Labs picks up the updated cert as well. The SSL Labs DROWN test, however, hasn’t caught up. It seems to think that the wildcard cert is still in use on the host.

Hi Again Ivan,
This is separate from my earlier comment and I think it’s more on point with your blog and less asking for you to give me all the answers to make my life easier. :) BTW, the answers you provided are great and much appreciated.

Now that you’ve helped me understand how to understand and check for compromised servers, I’m hoping to find out what in theory can happen to a compromised server:

So, lets say in my scenario where other servers outside of my control that share the same certificate and key are compromised and the bad guys are able to get the private key from one of these servers. What would be an example of how the attack could look like on the other servers that has SSLv2, SSLv3, and RC4 ciphers disabled but whose private key is now compromised? What are the possible things the bad guys could do and using what methods? I.e. (and I’m just making this up) They could directly insert data into the compromised server, using a MITM scenario, they could read all traffic to my server, change information from and to my server, etc. In theory, what would be the logical or expected progression of the attack using the private key they now have? I’m just trying to find an overview of what theoretically could happen, and not specific information unless there are known attacks that have been documented and there is hard data on what the attackers were able to accomplish.

Lastly, I was looking for books on securing web servers and saw your book titled “Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications.” Given my very basic level of understanding, would that be a good starting place for me or would it be too advanced? And if that’s too advanced, is there another “primer” level book that could get me up to speed?

In general, it’s never a good idea to share certificates and keys among unrelated servers. In the worst case, if you’re sharing the same key and certificates with some other servers that are subsequently compromised, whoever got the private key can impersonate your servers and perform man in the middle (MITM) attacks against your users. In some cases it might be able to decrypt traffic passively.

There are other cases when you’re not sharing the keys, but there are two separate certificates for the same hostnames. This case is not as easy to exploit, but sometimes application-level vulnerabilities (e.g., XSS) can be transferred from one host to another.

And, of course, in case of DROWN, either a shared key or a shared certificate can be exploited if there are other servers with SSLv2 enabled.

Regarding my book, I think it will be a perfect introduction for you. It’s effectively a reference guide that takes you step by step through everything you need to know, starting at the beginning. Good luck!

Probably not a bug; most likely the same server name is used in both certificates. The DROWN section in the report will indicate which is the case. If you share your hostname with us we might be able to help.

hmmmm … actually that’s a wildcard cert, but they are not the same, I know a wildcard cert leackage may lead all the domains in danger, maybe that’s the reason why? Sorry that my English is not so good, my description my not be so precise, hope it didn’t misunderstand you.

I have a number of servers whose SSL certificates share the same name, but they’re all different key pairs.

Example: mail.server.org has a *.server.org cert, and is running SSL2 for silly legacy reasons. http://www.server.org has a *.server.org cert, but it’s a different one, and is only running TLS. Is http://www.server.org vulnerable in this case?

It can be vulnerable, even if the keys are different. If the mail server is vulnerable “enough”, then its certificate can be broken and used against the web server, even if the key is different. That’s the theory; in practice, the risk is probably not very big.

Hey Chris, we are testing if the RSA key is the same. However, you will be vulnerable to DROWN if only the names in the certificates match (and the certificates and RSA keys are different). The problem is easy to solve: turn off SSLv2 on the indicated server or change its certificate so that it doesn’t contain your hostname.

I’m getting an “F” for “DROWN (Experimental)”. TLS 1.2 is the only protocol that’s even installed or active on the WAF. Is this a false positive? Are there configurations that make TLS 1.2 vulnerable to DROWN? The WAF is offloading all our SSL decryption so the test is running against the WAF’s TLS 1.2…. And there are hundreds of other sites behind the WAF that all test “A”.

I owe someone an answer since I socialized that this test site is the definitive word in all things SSL configuration. Now that we have this report I have to take action :)

Has the private key on your WAF been reused on any other servers that may have SSL2 enabled? If so you should generate a new private key and certificate, and upload it only to your WAF server.
DROWN is a key-reuse vulnerability.

I’m testing against server, let’s call it server-ok, which uses TLS 1.0+ (SSLv2 and SSLv3 disabled).
We have another legacy server which still has SSLv2(we will disable, but that’s another talk), let’s call it server-bad.
Server-bad have UCS (multidomain) certificate installed and that certificate also contains domain from server-ok.
Server-ok domain now have it’s unique certificate/key pair (previous it was previous mentioned UCS), but it still gets F grade. Is it correct?

@Kaspars I can’t seem to respond to your post directly. If you have a self-signed (or otherwise not publicly trusted) certificate on an SSLv2 server and SSL Labs is deciding that certificate is a cause for DROWN somewhere else, that’s a bug in SSL Labs. Please get in touch with the name of the server and the developers will take care of it.

i am testing my website URL and i applied SSL certificate on that which is unique and not other site is using same certificate or KEY which i am using still is showing me vulnerable to the DROWN attack and its set grade F and also its showing Yellow color for Key exchange.
Could you please let us know how can we resolved this ?

To resolve your problem, disable SSLv2 on the servers identified in the SSL Labs report. At the bottom, where DROWN is reported, there will be a list of IP addresses whose insecurity affects the server you’re testing.

I very much appreciate the service and make use of it.
Being in the possession of a wildcard certificate I used that certificate on several devices.
I noticed that your test gave me a low rating (F) although I did much to prevent this.

The culprit was a recording device which has that same certificate installed. The recording device also supported SSL2
It wasn’t only that. That device is no more in my control and I have handed management to another party a while ago (not realizing I had that certificate installed). This also ment my keypair is compromised.
I made a reissue of that certificate.

It then still didn’t adapt the score of my certificate.
It now claimed that it has the same hostname. All correct there…

I then decided to revoke the old certificate. At this moment the certificate on that server is revoked.
But it still is giving me the same error message.

Is it just being late and will this be solved later on or are these certificates not tested for validity?

I think you did the right thing; you’re safe as you can be, given that you don’t have access to that system any more. (On the positive side, DROWN is not a likely attack vector.) As far as I am aware there is currently no revocation checking done in that case, but there should be. I’ve opened this ticket to track progress on this issue: https://github.com/ssllabs/ssllabs-scan/issues/451 Thanks!

I now bumped into something else.
I now know that those recording devices made by QNAP support SSL2.
We just installed a new one at a client’s site. Now I used the SSL Labs test to check if that new model is any better.

It seems it isn’t.
But now your website is giving me a list of more than a 1000 IP’s that have such a QNAP recording device.
These IP’s all have the same self-signed certificate.

Shouldn’t SSL Labs (or the other party) be more discrete with this info?

I’m not giving my own IP here, but one out of that list 2.230.2.220
Maybe you can edit my post??

We’re now several months later and I only just recently found out that the site for which I revoked the certificate can still be accessed with Chrome without any warning. This is not possible using Firefox or IE. I know some more now about the reasons behind it. Chrome is not using the traditional “CRL” (Certificate Revocation List) that was designed for this purpose because that itself can become an issue.
I’m somewhat embarrased to find out this late about all that, but on the other hand it’s a bit strange as well as its competitors still honour the CRL’s and that “rogue site” is identified as such by Firefox and IE.

But I’m more interested now in finding out the best way of dealing with my current situation.
I would first like to clarify a bit better what my situation is. In January I decided to stop using my wildcard certificate on many devices. I therefore reissued the certificate and started using the new certificate on a few servers for which only I have administrative access. I then started to replace the old wildcard certificates on the remaining devices with self-signed certificates. In that process I found out that I handed over administrative access to one of those devices to a third party. I believe this third party is not even aware of any certificates, but that’s beside the point. This 3rd party has access to the private key of my wildcard certificate. It’s not the same key as the one running on my important servers, but it still is valid until the end of this year. After revoking that certificate at my SSL-provider I was under the presumption that I fully corrected my mistake and went on with my business.

More by chance I tried to access that rogue site with Chrome and to my astonishment it was regarded as a safe site. This is because Chrome does NOT check the CRLS.

How can I solve this? It seems I need to use “OCSP stapling” on the legitimate sites I am running. Although I’m not running it on all sites I am doing that on most.
Now I believe I should reissue my certificate with a “OCSP must staple” directive and use that on my legitimate servers. Would that solve my predicament?
I then should probably replace all my certificates with that new one and also revoke the one I’m currently running.

If there’s an SSL v2 server running somewhere, the DROWN vulnerability can be to attack other servers that either 1) use the same private key or 2) match one of the hostnames in the certificate (of the SSL v2 server).

As for private key sharing, I think the common scenario is that you want to use the same wildcard certificate on several servers, which leads to private key sharing. Other scenarios, perhaps mass-hosting environments?

To be safe, just don’t use SSLv2 on any servers that have certificates with your hostnames in them. And don’t share private keys, of course.

SSL Labs relies on an external Censys API for one part of the DROWN test. That API is no longer operational it seems. We will reach out to the owners to see if it can be fixed. That message indicates that there is a problem with the SSL Labs test, not with your site.

As far as I am aware, SSL Labs uses Censys only to find candidates for testing. A host is marked vulnerable only if it fails the test. Thus, I don’t know how often Censys is updated, but that shouldn’t impact the grade. If you think that your grade is incorrect, please open a ticket here https://github.com/ssllabs/ssllabs-scan/issues and provide your hostname. Thanks!