1

Web browsers are off course checking that field, but some third party libraries for languages like perl don’t perform it (they check /keyUsage= but not /extendedKeyUsage=).

So for example, I would need a certificate authority that would allow to put anything inside inside the /cn= (a field which can be typically used for subscriber in the case of s/mime certificates since the /keyusage= field allow encipherment but not for server authentication). Badssl doesn’t offer such testing option (and probably not any other website).

Why not make your own ca? Because I’m talking about crappy stuff which have all their certificate hard coded in compiled shared objects?
Also, in my case (for the responsible disclosures I’m planning), the bug shouldn’t be hypothetical. I mean a certificate authority should deliver certificates with arbitrary websites in the /cn= fields but without server authentication in the /extendedKeyUsage= field.

What kind of certificate typically don’t allow for server encipherment in their /extendedKeyUsage= field and don’t have the /cn= part verified ? An s/mime certificate !
If such certificate get used with a web browser for man in the middle, the web browser will detect the certificate doesn’t allows server authentication in it’s /extendedKeyUsage= field an refuse it. But if a tool doesn’t check /extendedKeyUsage= field contents, man in the middle would work.

user2284570
  • 1,402
  • 1
  • 14
  • 33
  • I think PersonalSign2 can allow anything in the `/cn=` but I’m unsure (and I’m unwilling to pay). In which case, an other certificate authority would be required (I don’t know which one). Or tools like https://badssl.com but which allows to test `/extendedKeyUsage=` – user2284570 Jan 12 '18 at 18:34
  • *"... but some third party libraries for languages like perl don’t perform it"* - I cannot reproduce this, neither with Perl (IO::Socket::SSL) nor with Python (ssl module). If certificate validation is on both will neither accept certificates which are only for S/MIME or client authentication in my tests. Given that these modules don't explicitly set a purpose but rely on OpenSSL I would suggest that this is already handled internally by OpenSSL itself. – Steffen Ullrich Jan 14 '18 at 20:16
  • @SteffenUllrich They use openssl, but perform validations steps manually instead of calling a higher level openssl’s function. Do you mean you tried to connect to website with a matching `/cn=` or Altname but without sever authentication in extended validation ? – user2284570 Jan 15 '18 at 20:08
  • Correct. I've created certificates with different extended Key Usage signed by my own CA and then tried to use these as trusted. It worked only for the one which had a key usage for SSL server authentication. – Steffen Ullrich Jan 15 '18 at 23:20

1 Answers1

1

a certificate authority should deliver certificates with arbitrary websites in the /cn= fields but without server authentication in the /extendedKeyUsage= field.

"Arbitrary websites" sounds like something that you may or may not be the admin for.

Let me get this straight. You want a publicly-trusted CA (trusted by real devices out in the world) to issue you a malformed / invalid TLS server certificate (because the EKU is wrong), for the purpose of your security research? First, I would guess that most commercial CAs issuing TLS web certs are hard-coded to populate the EKU field correctly. Second, I am not an expert on the CA/Browser Forum rules, but issuing intentionally malformed / malicious certs off a publicly-trusted root seems like the kind of thing that could get a CA in a lot of trouble. Good luck finding one.

ORIGINAL ANSWER:

I would need a certificate authority that would allow to ...

Why not make your own CA?

Whenever I'm testing cert validation stuff, I make a quick openssl CA using openssl. If the openssl command-line intimidates you (I don't blame you) then I recommend the CA.pl convenience wrapper. Add your new root CA to the trust store of whatever app you're testing and then you have the ability to produce any kind of bizarre cert you want and make sure the application rejects it properly.

(note, you sometimes need to get pretty down into the weeds of openssl config files depending on which certificate fields you're trying to manipulate or how you want it to do the signing.)

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • `Why not make your own CA?` Because I’m talking about crappy stuff which have all their certificate hard coded in compiled shared objects? – user2284570 Jan 12 '18 at 18:43
  • Perhaps you should clarify your question then? – Mike Ounsworth Jan 12 '18 at 18:48
  • Done ! I also added that the issue shouldn’t be hypothetical. – user2284570 Jan 12 '18 at 18:53
  • **I need a trusted certificate wich allow encipherment but not web server authentification** (if server isn’t authenticated you can man in the middle it).If you request an s/mime certificate, the certificate you'll get won't be have the server_auth (`1.3.6.1.5.5.7.3.1`) in it's `/extendedkeyusage=` which would prevent you installing it on a server. and in the case of an email certificate, it’s the `/emailAddress=` field which is relevant not the `/cn=` which normally contains the name of the sender. **I don’t need arbitrary `/extendedKeyUsage=` values, but arbitrary `/cn=`.** – user2284570 Jan 12 '18 at 20:40
  • Normally certficate authorities check only you own the `emailAddress=` field for s/mime, not the `/cn=` field.Please edit your answer. – user2284570 Jan 12 '18 at 20:41
  • You can suggest an edit if you want to. I am still super unclear what you're trying to achieve. They way I understand your question, you are looking for a publicly-trusted cert to give you something that will enable man-in-the-middle testing, which I can't imagine any CA in their right mind is going to give you. Unless it really is as easy as you say with S/MIME certs, in which case why are you asking a question and not just doing it? – Mike Ounsworth Jan 12 '18 at 22:00
  • If such certificate get used with a web browser for man in the middle, the web browser will detect the certificate doesn’t allows server authentication in it’s extended key usage field an refuse it. But if a tool doesn’t check `/extendedKeyUsage=` field contents, man in the middle would work. – user2284570 Jan 13 '18 at 10:26
  • The problem is to have a certificate authority that still process s/mime certificates through a csr. Something usual in the 90’s but rather rare today (Global sign propose doing it but edit generated csr). – user2284570 Jan 13 '18 at 10:44