Is there a custom SSL certificate authority I can add to my browser?
We use lots of internal urls like
http://www.somproject.somebranch/ for working on individual branches
It would be cool if there was some service I could add to my browser/OS which would let me use a single cert (or easily generate certs) for non-real domains. Does this exist, or is this just a #firstworldproblem?
The point of a custom CA is that you have to create it yourself (by being the holder of the private key for the CA certificate, in particular). Importing just any available CA certificate into your browser would mean that anyone with its private key could issue certificates recognised by your browser (usually for any site, unless there is a specific policy).
There are a few tools to manage a CA:
OpenSSL's CA.pl: it's a script that comes with OpenSSL. It's quite basic but highly configurable (via openssl.cnf).
TinyCA is a front-end to OpenSSL that helps you manage your certificates with a GUI. It's a bit more manageable than CA.pl.
OSX comes with its own interface in Keychain.app.
There are a number of other tools listed in this Security.SE question: EJBCA, OpenCA and XCA.
Most of the hard work is the administrative part (not so much sysadmin, but paperwork) in general. If it's just for you, EJBCA or OpenCA might be overkill.
Related
I'm in the process of connecting to an external server and am making a CSR to receive some certificates from them, and I have some questions regarding this.
Some tutorials state that you should save the private key as this will be used during installation of the certificate. However when using the Windows certificate manager (certmgr.msc) I think it generates the private key under the hood, and the resulting CSR-file does not contain any private key. So in that case I won't have access to any private key at all, unless I can export it from the certificate I receive later? I was also under the impression that a private key is not needed for installation of the certificate as it is just imported into the certificate store? If that's the case, does the private key have any use besides generating the public key?
I was also wondering about the location the certificate can be used. It seems that the certificate can only be used on the server that the CSR was created. However, my application will run on Azure so how can I get a certificate that can be used in the cloud?
Last question: The certificate provider supplies three certificates, one root, one intermediate and one "actual" certificate. What is the purpose of these different certificates?
Appreciate any insight or guiding to this process. There are a tons of guides out there, but many of them seem to contradict each other in some way or another.
(certmgr.msc) I think [] generates the private key under the hood,
Correct. You generate the key and CSR, send the latter to the CA, and (we hope!) get back a cert containing your publickey and identity (for SSL/TLS your identity is your domain name or names), plus any needed chain certs (usually one intermediate and a root, but this can vary). You import the cert to certmgr, which matches it up with the existing, stored but hidden privatekey to produce a pair of cert+privatekey which is now visible and usable.
To use this in a Windows program, like IIS, you also need the chain cert(s), see below, in your store -- for these just the cert(s) not the privatekey(s), which you don't have and can't get. If you use an established public CA like Comodo, GoDaddy, LetsEncrypt their root is usually already in your store, and if you use a CA run by your employer their root may well be already in your store for other reasons such as email; if not you should add it. The intermediate(s?) may or may not already be in your store and if not you should add it(them).
I was also under the impression that a private key is not needed for installation of the certificate as it is just imported into the certificate store?
It is needed, but you don't provide it, because it's already there.
It seems that the certificate can only be used on the server that the CSR was created. However, my application will run on Azure so how can I get a certificate that can be used in the cloud?
Initially, it is usable only on the system where the CSR and privatekey were generated. But using certmgr you can export the combination of the certificate and privatekey, and optionally the cert chain (which export wizard calls 'path'), to a PKCS12/PFX file. That file can be copied to and imported on other Windows systems and/or used by or imported to other types of software like Java (e.g. Tomcat and Jboss/Wildfly), Apache, Nginx, etc.
Note however that the domain name or names, or possibly a range of names matching a (single-level) wildcard, that you can use the cert for is determined when the cert is issued and can't be subsequently changed (except by getting a new cert).
The certificate provider supplies three certificates, one root, one intermediate and one "actual" certificate. What is the purpose of these different certificates?
Certificate Authorities are arranged in a hierarchy. Running -- particularly securing -- a root CA is difficult and expensive. As a result certs for end-entities (like you) are not issued directly by the root, but by a subordinate or intermediate CA. Sometimes there is more than one level of subordinate or intermediate. Thus when your server uses this certificate to prove its identity, in order for the browser or other client to validate (and thus accept) your cert you need to provide a 'chain' of certificates, each one signed by the next, which links your cert to the trusted root. As I said, one intermediate is common; this means your server needs to send its own cert, which is signed by the key in the intermediate, plus the intermediate cert, which is signed by the key in the root. The root needn't actually be sent, because the client already has it in their truststore, but it may be, and it is also desirable to validate the chain yourself before using it and for that you need to have the root even if you don't send it.
First let me state that I am a Linux noob. I am learning as I go here. Here is my situation. I have an Ubuntu 16lts server, with apache. The software we just installed comes with "samples" These samples are stored in the same directory structure as the program. The instructions have you add an alias and a directory to the apache2 config file. Like so
Alias /pccis_sample /usr/share/prizm/Samples/php
This actually worked :)
However now we want to make sure this site is SSL. I did manage to use openssl to import to Ubuntu the certificates we wanted to use. (i am open to using self signed though at this point its non prod so i dont care)
In trying to find out the right way to tell Apache i want to use SSL for this directory and which cert i want to use. Things went wonky on me. I did manage to get it to use ssl but with browser warning as one would epexct with a self signed cert. I had thought that i could just install the cert on our devs machines and that would go away. But no dice. Now in trying to fix all that i just done broke it. SOOOO What I am looking for is not neccessarily and spoon fed answer but rather any good tools, scripts, articles tips tricks gotchas that i can use to get this sucker done.
Thanks
You need to import your certificate(s) into the browsers trusted store. For each browser on each machine you test with. "What a pain!" you probably think. You are right.
Make it less painful - go through it once. Create your own Certificate Authority, and add that to your browsers trusted certificates/issuers listing. This way, you modify each one once, but then any certificate created by your CA certificate's key will be considered valid by those clients.
https://deliciousbrains.com/ssl-certificate-authority-for-local-https-development/
Note that when configuring Apache or other services, they will still need an issued/signed certificate that corresponds correctly to the hostname that is being used to address them.
Words of warning - consider these to be big, red, bold, and blinking.
DO NOT take the lazy way and do a wildcard, etc. DO keep your key and passphrase under strict control. Remember - your clients will implicitly trust any certificate signed by this key, so it is possible for someone to use the key and create certificates for other domains and effectively MITM the clients.
I have obtained a free Open Source Developer certificate (with Code Signing as only usage) from Certum in reply to a web form instead of a regular CSR file. The Certificate has no installation issues on Windows and forms a trusted chain along with the corresponding intermediate and root CA certificates in any keystore management tool I have tried. No problems so far.
Nevertheless, besides the bright side of becoming somewhat acquainted with the subject after frustrating studying it for several days (my only purpose was to sign jar files for my online solfège school), I haven't been able to import the certificate to any keypair on neither toolkey, KeyStore Explorer, CERTivity, nor OpenSSL, because the public keys don't match, (I think) obviously.
I (probably mis)understand that the public key from a requesting keypair is conveyed to the CA by the CSR file and included back in the certificate reply, but in my case there is no CSR file.
I plainly admit my ignorance, and would just like to know:
If is it even possible (with all security risks involved) the procedure of tailoring a keypair to match an existing such a certificate (an Openssl command, perhaps), and
if, as I'm afraid of, the answer is no, what is such a "CSR-file-orphan" certificate useful for?
Any enlightment will be greatly appreciated.
Jesús Díaz
Certum probably have created the CSR for you if you didn't submit one.
In that case, a (public-private) key pair would have been installed on your computer.
You will probably have to export the key pair from Windows keystore to a file so that you can import it to another keystore.
guide from microsoft
with screenshots
another way
To answer your questions:
since the certificate has been created, you won't be able to create a key pair for it.
it is actually not a CSR orphan certificate
You might want to make another request from Certum and inform them that you would like to provide a CSR
I need to sign an enterprise Windows Store app I've developed ,so that users can sideload it into their devices.
I'm in the process of obtaining a code signing certificate from GoDaddy. A lot of the next steps are still hazy for me - any additional details will be appreciated.
What I've done so far
The application is tested, and I was able to deploy it on machines that have a developer license.
Purchased a code signing certificate from Daddy but didn't know what to do next (based on past experience I thought I needed to generate a key pair and a certificate signing request on my developer machine)
Called GoDaddy support who said I actually need a driver signing certificate rather than a code signing certificate. The cost was the same so they instantly switched my purchase.
It turns out there is an automatic process for generating a CSR on Windows, but you have to use Internet Explorer for that. Apparently, the cryptographic stuff is somehow handled transparently by Internet Explorer and the GoDaddy website. I would love to know more about what is actually going on there.
As part of the process you need to provide the legal name and official address / phone of the software publisher (my client in this case).
Once you submit the request, it has to be approved by GoDaddy (who should somehow verify that I am authorized by the publisher to sign code on its behalf).
Next steps
I assume GoDaddy will need to receive some documents from the publisher. I'd love to know how that process works and how long it takes.
Once the certificate is issued, I expect there will again be some easy way to install it on my development machine. Question: is there a way to move the keys and the certificate to another machine?
I also expect Visual Studio (I'm using 2012 Express edition for Windows 8) to be able to use the certificate when creating app packages. Will I need to do some special setup for that or will it be straightforward (part of the "Create app package" wizard) ?
Some of the details I've put on the certificate signing request will eventually be visible on the actual certificate (visible to the persons installing the application). Which ones?
After completing the process here are my own answers:
It turns out the GoDaddy support representative was wrong when
advising me to use a driver signing certificate. I needed a code signing certificate.
The certificate does not show the details of the contact person (which are included in the certificate signing request). You can see the certificate details before you submit the request (I missed it initially). In my case the details shown are the company name, city, state and country.
The documentation requirements depend on the company requesting the certificate (in some cases they may not need any documents at all). GoDaddy has very friendly support, so you should can the requirements from them. The process can take a few days to complete (but they may be able to help in doing it faster).
When using Internet Explorer both for the certificate request phase and installation phase, the process is seamless. I believe it uses Microsoft's Certificate Enrollment API (which is also described in this MSDN blog post)
As mentioned by JP Alioto, the process for using the certificate is described in the article "Signing an app package (Windows Store apps)". To use the new certificate in a specific project:
Open the projects .appxmanifest file
Go to the "Packaging" tab
Next to the publisher field, click "Choose Certificate"
In the dialog that pops up click "Configure Certificate" and select the drop down option "Pick from certificate store ..". The certificate should be available as one of the options.
To export a certificate, you can use the following process:
Run certmgr.msc
Locate the certificate
Right-click > All Tasks > Export to launch the certificate export wizard, which has an option to export the private key
Warning: the private key is supposed to be personal and you should protect it. It is probably OK if you copy it to another machine that you control (assuming nobody can snatch it in transit). Sharing it with someone else may be risky. I was not able to find information about how exactly the private key is used by Windows, but it may be a bad idea to have several people share a private key.
To import the certificate and private key from a PFX file, right click on the file in Windows Explorer, and elect "Install PFX". This will launch a straight-forward "Certificate Import Wizard".
Lots of stuff there. :) There are are few documents you need to read:
Deploying Metro style apps to businesses
How to Add and Remove Apps
Signing an app package (Windows Store apps)
Reading and understanding these documents will give you a better idea of what's going on. Are you sure the enterprise you're deploying for does not already have a trusted root certificate that they deploy to their desktop images? If they do, it may be easier to use that private key to sign the app. (The only reason a public certificate authority is recommended is that you will then not have to deploy the certificate to the target machines.)
You can move certificates (and private keys unfortunately) in the evil PFX format which is basically a PKCS #12 portable key file. But, be very careful how you move that file around. It contains both your public key and your encrypted private key.
I need to see how a web application will work with HTTPS. But I can't really find much information around about it. I tried to set up my local Apache but I can't find a CA autorithy to sign my certificate... Hints? Suggestions?
The possibilities to consider are:
Generate your own certificate (self-signed certificate)
Get a certificate issued by a known issuer
Get a certificate issued by an issuer not recognised by the browser
Nr. 1 is probably the most widely used solution. You can find instructions here. The only disadvantage is that browsers will complaint about the unknown CA. In Firefox, you can just add a permanent exception and get rid of the warning. (Neither Chrome nor Internet Explorer seem to provide such option.)
Nr. 2 normally costs money so it isn't a popular choice for dev environments.
Nr. 3 can be obtained for free (see https://www.cacert.org/) but they also trigger a browser warning. A difference with nr. 1 is that you have the possibility of adding the CA to your browser's trusted authorities; however, that's a serious decision that requires serious consideration because of its security implications. In general, I would not recommend it for mere testing.
Self-signed certificates (as already mentioned) are probably the easiest option for a single host.
If there are a few hosts, you could create a mini CA of your own. There are tools for this, for example:
CA.pl: a script provided with OpenSSL.
TinyCA: a tool with a GUI.