Codesigning : Part 1 : The Request

From DataFlex Wiki
Revision as of 19:09, 1 February 2020 by Wil (talk | contribs)
Jump to navigationJump to search

Getting a codesign certificate for Microsoft Windows is still a bit of a confusing and frustrating process, so figured to write out the steps.

There are some parallels with getting a certificate for your website, but compared to how transparent things _can_ be down there, the process for getting a codesign certificate is everything but transparent and I tried several different providers over the years. For the record I also provide certificates for a number of my clients, so have gone through this a number of times.

Who to use?

If you're looking for a recommendation on who to use?

From my point of view they are all bad (or good depending on your point of view), choose the cheapest, or where you get the best service.

You are in the market of buying bits and bytes and they all provide the same bits and bytes.

The main difference is the certificate chain you get to use and the associated trust that they claim that this will provide (according to the snake oil vendor Certificate Authority). The sales item you sometimes see where they talk about how high the warranty is? It's bogus as there is literally nobody ever who has been able to claim such an insurance. 1 2

For a codesign certificate you have to go through a process with the supplier of the certificate where you can proof you are who you are. If you're a company, then they will want something like a recent chamber of commerce abstract or a Dun and Bradstreet (DUNS) number. They might also try to contact you on a phone number that you have to provide.

Now the main thing they really need is a so called a "certificate signing request" file, or a .csr file. There are two main ways of getting this.

Creating a CSR via a browser

This is a bit of a weird process as not all browsers are supported and even when the Certificate Authority (CA) website say things like "Firefox is supported".. well that is history already as the old keygen interface most of the Certificate Authorities depend on has been removed and they do not yet support the new WebCrypto functionality provided by all modern browsers. 3 So utterly confusing.

The only one that does work, AFAICT on January 2020, is ... Internet Explorer.

So no MS Edge, no Chrome, nope.. Internet Explorer. In the end this is also where you manage your certificates, so Microsoft can take part of the blame.

Generating the csr here is a matter of following the steps that your Certificate Authority (CA) has documented.

Note that the private key that is also generated is never send to the CA, nor is it ever provided to you. It is kept somewhere by Internet Explorer.

You _must_ use the same browser on the same machine later on to import the certificate from your CA so that you have both public and private key. Without the private key you won't be able to sign anything!

Create a CSR via openSSL

This personally has my preference, but beware that you store the private key generated by the process on a secure location and don't loose it (don't ask) 

 $ openssl req -nodes -sha256 -newkey rsa:4096 -keyout private.key -out onetimeonly.csr

The above command will generate an RSA 4096 bit keypair with a SHA-256 hash.

The private key will be in file "private.key" and the csr that you have to provide to the CA is in the file "onetimeonly.csr". As the name suggests, the "private.key" is a sensitive file and should be kept in a secure place.

OK, here we go if you type the above and press enter you get: 

 $ openssl req -nodes -sha256 -newkey rsa:4096 -keyout private.key -out onetimeonly.csr

 Generating a 4096 bit RSA private key
 .....................................................................................................................................................................................................................................................++
 ..............++
 writing new private key to 'private.key'
 -----
 You are about to be asked to enter information that will be incorporated
 into your certificate request.
 What you are about to enter is what is called a Distinguished Name or a DN.
 There are quite a few fields but you can leave some blank
 For some fields there will be a default value,
 If you enter '.', the field will be left blank.
 -----
 Country Name (2 letter code) []:NL
 State or Province Name (full name) []:Noord-Brabant
 Locality Name (eg, city) []:Eindhoven
 Organization Name (eg, company) []:VDF-Guidance
 Organizational Unit Name (eg, section) []:Open Source
 Common Name (eg, fully qualified host name) []:www.vdf-guidance.com
 Email Address []:info@vdf-guidance.com
 
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:

What Did I fill in and why?

Country code, this should be your country and is required.

State or Province Name, this is optional, but advised.

City name: required

Name of your company: required <-- this is the name people will see when installing your software!!

Organizational Unit: Optional

Common Name: we tend to use domain names here. This can be a tad confusing, but they are unique and is a required field. Note that you cannot use the certificate at your website host, it won't even work.

Email Address: required, use the email address that you want to have tied to this certificate.

Do not put a challenge password here.


to be continued soon...

External links

1. https://www.troyhunt.com/extended-validation-certificates-are-dead/

2. https://scotthelme.co.uk/do-ssl-warranties-protect-you-as-much-as-rocks-keep-tigers-away/

3. https://textslashplain.com/2020/01/19/retiring-internet-explorer/

Retrieved from "https://dataflex.wiki/index.php?title=Codesigning_:_Part_1_:_The_Request&oldid=3149"