Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
I ran this command: I have a fixed IP and received CSRs for my 2 domains from my hosting service, omnis.com. How do I ask for my SSL certificates to email back to them?
It produced this output:
My web server is (include version): Linux of some sort
The operating system my web server runs on is (include version): Linux of some sort
I can login to a root shell on my machine (yes or no, or I don’t know): I don’t think so. I have FTP access.
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): The panel just says account manager at the top, no program name or version, “All systems copyright Omnis Network 2018. All rights reserved.”
Omnis says you will give me the certificates, and that I will email them to Omnis, and the Omnis admins will install them. Can help?
The easiest way would be to use the (third-party) web-based interface at https://www.zerossl.com/ and follow its instructions. You should be able to use an externally-generated CSR. The site will prompt you to make changes to your own site in order to prove your control over the requested domain names to the Let’s Encrypt CA.
This is not necessarily a good match for Let’s Encrypt, because Let’s Encrypt is ideally meant to be used in environments where you can set up automated renewal. Our certificates currently expire every 90 days, so you’ll have to repeat this process relatively frequently.
Hi @schoen
(just now, free with quarterly work is better than expensive yearly, heh)
OK, I have received the CSRs from my hosting provider, one for each website. They look like
-----BEGIN CERTIFICATE REQUEST-----
MIIC…snip…nXZo=
-----END CERTIFICATE REQUEST-----
I’m working with zerossl.com, but am having trouble following their instructions. I finally figured out about the terms of service checkboxes, but the TOS documents are also hard to understand. I did get the file posting to work. I’m going to tackle this again soon, trying to be methodical, and report back. I think my biggest problem is that the pages talk about things using different names at different times, and I’m having a hard time connecting the ideas. For example, is the “account key” the same thing as the “LE key”, and is it the string labeled “RSA PRIVATE KEY”? Or is that possibly the “domain key”? And how does that relate to the “domain certificate”? I suspect the file that has two “BEGIN…END CERTIFICATE” sections is the domain certificate and the issuer’s certificate, that I’m supposed to give back to the hosting techs. I’ll try again with my other website soon and try to figure out how many alphabet soup files are involved and what their names are. By the way, am I supposed to include the -----BEGIN CERTIFICATE REQUEST----- and its END matching line when I paste into the boxes? Thanks for helping SSL-noobie me take a step forward.
Yes, you're going to have two different keys here. The account key (which the site also refers to as a "Let's Encrypt key") identifies an account, which allows you to issue certificates. You use this instead of a password. Most ZeroSSL users allow ZeroSSL to generate this for them, and you can then save it so that you can re-use the account later rather than creating a new account each time.
The private key for the certificate might also be called the domain key. When you use an externally-provided CSR, you don't actually possess this key. In your case, only the hosting provider possesses the private key corresponding to the certificate; it's something that they generated and then used to create the CSR. (There are different models for this, including some where you would generate this private key yourself—but it looks like that's not what your hosting provider wants you to do here.)
The domain certificate is public data that refers to the certificate authority's confirmation that the person or entity that possesses a certain private key also controls a particular domain name (or combination of domain names). The certificate is what you get from Let's Encrypt at the end of the process and then have to share with your hosting provider. If you pass Let's Encrypt's validation (for example by creating the correct challenge files), Let's Encrypt will issue a certificate that contains the information indicated in the CSR (stating that whoever controls the referenced domain key also evidently controls the domain names, which is not obvious and which it is the CA's entire role to check).
Both the account and domain will keys will normally be an RSA PRIVATE KEY, but in the CSR model that your hosting provider is using, you never see the domain key; only the hosting provider has a copy of it. In this model the only RSA PRIVATE KEY that you will probably get to see is the account key.
The certificate refers to a "subject public key" which is the public key that (1) the certificate refers to the ownership of, and (2) mathematically corresponds to the domain private key. The connection between the subject public key and the corresponding private key is described at
You don't need to make use of any of these details in order to complete the certification process.
In this case, the entity that possesses the private key (here, your hosting provider) is able to use it to make cryptographic signatures that a verifier (here, the web browser of someone visiting your site) can confirm must have been made by the same entity that the certificate refers to, because the certificate refers to the matching public key. This is in turn how we can say that the certificate allows the browser to "know it's talking to" the intended site. Only that site has the necessary information to make digital signatures that match those that the certificate says it should be able to produce.
Yes, that should be right.
Yes, all of these are different kinds of PEM-formatted files, which is a common way of exchanging data related to cryptography. The BEGIN and END stuff I think originated with the PGP encryption software by Phil Zimmermann, and then the people devising the PEM standards must have chosen to imitate it. You should normally always keep these lines in place in order to allow the software (and also any human beings who have to examine the file) to confirm exactly what type of file it is.
I once found a really good introductory article about all of these things, and I've never been able to find it again! They've become pretty much second-nature to me since I've been working on PKI and crypto stuff for a while, but I think most people who deal with this process never quite understand what all of these files are meant for and what role they play in the process. (Note that if you use software like Certbot, it will usually be able to do the entire process for you without showing you any of the files. They all still exist, but Certbot takes care of obtaining and installing the certificate, so you typically don't have to paste anything or e-mail anywhere anywhere.) If I ever find that article again, I'm going to suggest it to everyone who asks these questions; its explanation was much clearer than mine and I think it included samples of the files themselves.
@schoen,
Here’s what I’ve got so far, may it help others:
[] Purchase hosting account at Omnis.com service, with fixed IP
[] Register URL anywhere
[] IF site is hosted elsewhere, copy it to local storage, clear out its emails, record the email addresses, and remove it from the other hosting
[] From Omnis dashboard, set up the URL
[] IF URL is registered elsewhere, modify its DNS records to be on Omnis’ DNS servers
[] copy from local storage to new hosting space (FTP? FileZilla works)
[] OPTIONAL set up email addresses
— site should be working http:// —
[] Ask Omnis for Certificate Signing Request (CSR) for site
[] Receive CSR from Omnis by email
[] ZeroSSL.com (in PaleMoon w/NoScript, allow script)
CERTIFICATES AND TOOLS in top bar, gives “FREE SSL Certificate Wizard”
START button, gives “Details” page
my email for contact
leave Domains blank
In the left box under the email, paste Let’s Encrypt key (if you’ve done this before, otherwise leave blank) including the lines
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
(The first time I did it, it gave me the key to use next time)
HTTP verification should be already checked
In the right box, paste your CSR including the lines
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
Check both
Accept ZeroSSL TOS, and
Accept Let’s Encrypt SA (pdf)
Click NEXT in the upper right corner - watch for need to allow more scripting.
The Verification screen should appear, with the domain name, file name, and file content they want to see to confirm your access. There’s a download button if you don’t want to build the file yourself.
via FTP, create two nested directories on the website (if they aren’t there) .well-known/acme-challenge
Upload the verification file to acme-challenge, then click NEXT
Receive the SSL certificate, containing both site and ownership sections. Can download.
[] email the certificate to support@Omnis.com , replying to the email providing the CSR
— once they install it, https should work —
I set up .htaccess thus:
# Turn on Apache tool for redirection of requested URL
Options +FollowSymLinks
RewriteEngine On
# Certificate is only good for bare URL foo.com, so
# Remove www. from bare URL and make sure https is enabled
RewriteCond %{HTTP_HOST} ^www.(.)$ [NC]
RewriteRule ^(.)$ https://%1/$1 [R=301,L]
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# This tests working for http://www.foo.com, http://www.Foo.com
# http://foo.com, http://Foo.com, https://foo.com, https://Foo.com
# But certificate mismatch for https://www.foo.com, https://www.Foo.com
# (Have seen comment that https prevents processing of .htaccess)