No.
The long version follows. I simplified a few things, so don't take every single statement as gospel, but the basic principles are correct.
You can't use the same certificate. You may be technically able to use the same private key, but it won't make your life easier and it would be bad for security.
From a technical point of view, the operations involved in securing a TLS connection and in signing some code for distribution are the same. Your server stores a private key, which nobody else knows. The server uses this private key to sign a {TLS connection handshake message}/{zip file containing your code}. Anybody who receives the signed data can verify that it was signed by someone who knows the private key corresponding to a certain public key K.
They know that the holder of the private key corresponding to K has signed something, but this is not useful unless they also know that you are the holder of this key. A certificate authority issues you a certificate, which says: ”I, undersigned, certificate authority, guarantee that raddevus.com is the holder of the private key corresponding to K“. Only, they say it in math and X.509 rather than in legalese. All this business of saying (in cryptographic language) who someone else is is called a public key infrastructure (PKI).
In addition to establishing a link between "raddevus.com" and K, the certificate states a number of restrictions on its usage. A certificate without restrictions could be dangerous. For example, this certificate doesn't allow you to, in turn, say, “I, undersigned, guarantee that google.com is the holder of the private key corresponding to K”. Well, you can say it, but browsers won't believe you, because your certificate doesn't allow you to make such claims. In technical terms, your certificate doesn't allow you to be a certificate authority. Your browser trusts the certificate authority when it claims that you are raddevus.com because its own certificate says that it's allowed to make such claims, and the reason it can get such a certificate is that it's satisfied the the certificate authority authorities. And your browser has a built-in list of certificate authority authorities that it's willing to accept.
You can look at what's inside a certificate to get a feeling. Modern browsers have an interface for this. In Chrome, open the developer tools and go to the “Security” tab. In Firefox, click on the padlock icon in your browser and follow the directions, e.g. click the padlock then “> (Follow connection details)” then “More Information” in Firefox. Navigate to the certificate details. Let's take https://www.smarterasp.net/ as an example; some highlights are:
- The “Subject” field lists
*.smarterasp.net. This is the website(s) that the certificate is valid for. If the website responded to requests for https://notsmartasp.example.com/ using this certificate, a browser would close the connection because the certificate is not valid for that host name.
- The “Certificate Subject Alt Name” field also lists
*.smarterasp.net, and smarterasp.net. This is the modern way of defining names, not supported by antique browsers.
- The “Certificate Basic Constraints” field states “not a certificate authority”. It also says “Critical”, that only means that an application that doesn't understand what a “Certificate Key Usage” is should treat the certificate as invalid; “Not Critical” would tell such an application to ignore the field.
- The “Certificate Key Usage” states “Signing” and “Key Encipherment”. If the server tried to use the key for something else, applications that use the certificate to verify something should reject it.
- The “Extended Key Usage” states “TLS Web Server Authentication” and “TLS Web Client Authentication”. (These are the English translations of the ASN.1 OID
1.3.6.1.5.5.7.3.1.) This is more precise than “Signing” from the other key usage field.
- Up above, the “Certificate Hierarchy” shows the chain from the trusted-by-your-browser certificate authority authority, down to the CA and the website.
If you want to sign some code, you need a certificate whose extended key usage includes the OID 1.3.6.1.5.5.7.3.3, which in English is known as “Code Signing”. To do this, follow the steps described in Microsoft's documentation. If you want to know more about how these tools work (I guess you do, or you wouldn't be reading this), read the old instructions. Note that the documentation mentions the requisite extended key usage (they call it “enhanced key usage”, but it's the same thing). The documentation also mentions a few other constraints on the certificate.
If you want to go further and establish the link between that certificate and raddevus.com, you need to get it signed in the Microsoft application distribution PKI, rather than in the TLS PKI. I'm not familiar with this PKI, I don't know how you get into it. I think it involves going through an application store.
While you may in theory use the same private key and generate different certificates from it, one for the web and one for code signing, it would be more work converting between formats than generating two keys. And using the same key would be a bad idea for security. Your web server's private key has to be on the web server because it is needed on each connection (to authenticate the website to the browser). On the other hand, your application signing key only needs to be used when you deploy a new release version of your application. If your server gets breached, you need to revoke its key, get a new one, and people attempting to visit your website and being attacked by a man-in-the-middle (who redirects connections that should go to your site, to their own site) will suffer. If your code signing key is compromised, then until people receive the revocation information, they will be at risk whenever they receive an application package signed with your key; that attack (distributing a dodgy executable) is rather easier to arrange than a man-in-the-middle. So you really should protect your code signing key better than your website authentication key.
Note that you can get a website .
if I can use that same cert to sign my .NET app. Specific OS application code signing usually control by a the OS standard and may not be compatible with SSL certificate standard.