Our web site is running on Ubuntu 14.04 LTS- Apache 2.4.7-PHP5-FPM and is secured by Let’sEncrypt. We are moving to Akamai CDN and they want the entire site (www.ourdomain.com) CNAMEd to Akamai.
As part of the process, they have procured a CSR for www.ourdomain.com from Symantec and have sent us the same in .txt & .pem format, with a request to sign it on our server using LetsEncrypt and then send them the signed bundle. They will then upload this certificate to their servers.
Now, my understanding is that I could configure OpenSSL on our server to create a CA and then sign the CSR sent by Akamai using using x509 or ca modules, but that would be equivalent to a self-signed cert because the Certification Authority would not be trusted.
So, is it technically possible to sign the Symantec CSR using LetsEncrypt on our server? I am doubtful, as our server already has LetsEncrypt certs for ourdomain.com and www.ourdomain.com and I believe that signing the Symantec generated CSR on our server with LetsEncrypt for the same domains will actually replace the existing certs on the server.
It would be great if someone could chime in on this curious issue.
Ok, so, CSRs are not really related to a CA. CA’s can have requirements about aspects of them, but they’re mostly CA-agnostic in general. I don’t know what Symantec may add to their CSRs, but I wouldn’t anticipate it upsetting Let’s Encrypt.
CSRs in general are just a specially formatted bundle of information: Domain name, SANs, some demographic info that’s often ignored, and very importantly, your public key corresponding to a private key you hold on to. A simplified but still accurate picture of what happens next is that once the CA gets this CSR, they process it and sign your public key and adjoining information with their private key. This is the certificate sent back to you.
So, you have a few options. If your CDN is unwilling or unable to let you specify a new private key, you have to use their CSR. However, if you can send them the private key of a CSR you generate yourself, no problem. Either way, you could just do something like use DNS validation and get a certificate from somewhere like https://zerossl.com/. You can let that generate a new keypair in-browser for you and get your cert, or give it your CSR and see if Let’s Encrypt can turn that into a certificate.
As for replacing the certs, not necessarily. You can issue multiple certificates for identical domains (up to rate limits) and it will not invalidate your previous ones. Of course, if you do this with certbot’s automated methods, then it will replace them itself. You can prevent this with --cert-only, I believe (check docs for Certbot). However, it doesn’t really matter if you replace them, the new one will still be valid and can be used in multiple places if you want.
Now, bear in mind there’s a 90-day validity period on these, so you’ll probably want to work with Akamai on getting this automated somehow.
It’s worth pointing out that Akamai claims to support Let’s Encrypt natively, meaning they should be able to perform all the necessary steps for you as soon as you CNAME your domain to them - key generation, domain validation, certificate issuance and deployment.
I’m not entirely sure what Symantec has to do with this, perhaps this was some kind of misunderstanding?
This is exactly my question, too, although I didn’t ask the Akamai guys in so many words. May be I should.
The explanation they gave for using Symantec was that they only used business validated certs on Akamai servers, and, apparently, they had a difficulty reaching the owner of the business on the number listed in the Whois. The funny part is that Symantec had exactly the same difficulty, so they finally decided to get just the CSR from Symantec and get the cert signed by us.
But, I wonder if they thought about the fact that any cert signed by LetsEncrypt would be valid only for 90 days.
The Akamai folks clarified that they don’t want the SSL itself generated by LetsEncrypt but just for their Symantec-procured CSR to be signed by LetsEncrypt on our server and the signed bundle to be sent to them. They will then use the signed bundle to get the actual SSL from Symantec.
I think you are getting confused and need to clarify first what it is you are trying to achieve (and communicate it here) rather than trying to do things you think are correct
usual process for getting a certificate
A) Create a CSR
B) Submit a CSR to a Certificate Authority also abbreviated as CA (both Symantec and Let’s Encrypt are certificate authorities)
C) Prove you own the domain that the certificate is being requested for (Symantec has several options one of which is to send a link to activate sent to the contact on the whois record)
D) Download the certificate and install it
You usually only work with one Certificate Authority usually for a given CSR so asking Let’s Encrypt to sign something that Symantec will issue a certificate for makes no sense. Neither does using a self Certificate Authority with OpenSSL (as no one knows about you certificate authority and will not trust it).
To progress I suggest you stop and ask a few important questions
A) Why are you obtaining a certificate - usually CDN’s like Akamai use their own Certificates for origin servers
B) Which certificate authority (Symantec or Let’s Encrypt) do you want a certificate from
C) What is it that you need (just the certificate?) and in what format to install on your Akamai control panel
I am confused, too, so I asked the Akamai people for a clarification. But, they insist they only want the signed ca bundle which they will send to Symantec for the actual SSL. Looking through the certbot documentation, I don’t see an option to merely sign the CSR using LetsEncrypt CA and then generating the ca bundle the Akamai folks are talking about.
Thank you for stepping into this discussion. The steps you outlined is what I have been used to, as well.
This afternoon, they said the original POC for our client had used an OV SAN certificate from Symantec, so they had wanted to continue that for the actual implementation. But, apparently Symantec had difficulty completing the business validation as they couldn’t reach our client over the phone, so they opted for a third party certificate to onboard to Akamai quickly.
Reading through their email trail again just now, I have tracked the source of the confusion to the following statement:
I’m attaching the certificate in .txt & .pem format. Could you get this certificate signed and give me the signed bundle. Upon receiving the bundle I will upload it on Akamai network.
It didn’t help that the Akamai solution architect kept insisting that they only wanted the CSR to be signed by LetsEncrypt and the signed bundle sent to them. Here’s what they said this afternoon:
We would need the CSR signed by Let’s Encrypt along with the certificate bundle provided by Let’s Encrypt.
It’s clear to me that they generated the CSR for a third party cert on the Akamai server and just want the SSL to be generated by LetsEncrypt on our server and sent to them for uploading to Akamai.
That does seem a lot clearer. It’s also a bit counterintuitive in the Let’s Encrypt context, because although we can support this workflow, we don’t usually encourage people to work with CSRs manually at all. The person you’re dealing with might even be in a position to complete this task without your assistance, depending on what kind of DNS delegation has been given.
Thanks. Indeed, Akamai could have done this themselves quite easily, although we maintain the DNS for the domain at Route53.
I pointed out to them that, for another site, we had chosen a different CDN provider, who quickly setup a Comodo DV cert for us on their CDN servers. All we had to to was upload a verification text file to the web root of our domain. Once the domain was verified by Comodo and the SSL installed on the CDN server, we just had to point our A records to their IPs.
The Akamai rep said “we would take stock of this situation and take this as feedback for better customer experience in future”, whatever that means.
Oh, yeah, this has ‘smrt’ written all over it. Besides the fact that under any other circumstance, practically, you can generate a CSR from the CLI, your control panel (if applicable) and the tools online to create these for you simply by entering your domain. The CSR can be sent to any trusted CA for validation. Save the .key in a safe place. When the authority approves the cert, as long as you’ve saved the private key that came with your CSR, you’re good.to install that sucker practically anywhere. I refer clients to this generator from DigiCert if they’re not as familiar with openssl on the CLI.
Can you not use a standard “openssl req -new -newkey rsa:4096 -nodes -out bull_shite_domain.csr -keyout bull_shite_domain.key -subj…$etc” if you want to have LE provide a multiSAN just like with the big boys in the industry?
If your original certificate was canceled/revoked, generate a fresh CSR and start over, especially if the CA couldn’t validate your client’s operational existence. That’s not the kind of thing I’d pass around with every validation failure. Both LE and the Symantec lines have been in the spotlight for abusive/unsavory usage and/or improper validation. Just like when you reissue a cert from a trusted authority. The CSR and key will change completely before reissuing even starts.
No disrespect, but if you’re still learning the ways of SSL/TLS and how certificates are issued, I’d suggest learning the method by which every other CA performs domain validation rather than starting with a peculiar situation with an even more peculiar 'authority."
@gohomeyouredrunk, thanks for your suggestions. No offence taken, but I came into the picture much later in this example, so it wasn’t my choice to start with an externally generated CSR and get it validated on our server. That decision was made by Akamai.
The server itself has been using LE certs for the domain since February this year and we’ve been using Route 53 DNS since two years. The Akamai requirement surfaced a month ago.
I am about the generate the SSL using LetsEncrypt on our server, but with the CSR from Symantec in .pem format that Akamai supplied to us. Looking through the certbot docs, it looks like I need to do the following:
use the --certonly and --duplicate flags, as the domain for which Akamai wants the SSL for CDN already has its own SSL on the server. As per the docs, “–duplicate tells Certbot to create a separate, unrelated certificate with the same domains as an existing certificate. This certificate is saved completely separately from the prior one”.
use the --manual flag with the dns or http challenge for domain verification.
I am still not sure how to pass the .pem (csr) file location/name to the command. Looking through our server, I find the .pem files for the previous CSR’s automatically generated at the following path:
In this case, though, I will need to use the provided .pem. So, if I upload the Symantec .pem to this path and rename it as 0007_csr-certbot.pem, would Certbot know to use this .pem for the new SSL?
Thanks, I did notice the CSR folders were auto-generated. I was looking at http://letsencrypt.readthedocs.io/en/latest/using.html#manual, but it didn’t have the specific command for the csr bit that your linked post does. I will use that, many thanks.
By the way, this means "separate [from other certificates that Certbot itself has already created for these domain names]", which doesn't apply to your case.
Also, --duplicate isn't relevant to cases when you use an externally-provided CSR because, when you use an externally-provided CSR, Certbot doesn't save your new certificate under /etc/letsencrypt. The options like --duplicate, --keep-until-expiring, --force-renewal, all refer to how Certbot treats existing certificates that it created under /etc/letsencrypt, but there won't be any such certificates in your case, either before or after.
@schoen, thank you very much for the clarification. I guessed as much because I spent a long time wondering if the --duplicate flag made any sense when using an external CSR because the cert files aren’t created in the usual letsencrypt paths.
For anyone faced with a similar situation, here’s my somewhat crude solution to upload the provided external CSR to the server and generate the certificate:
Download the external csr (provided in .pem format) to desktop
Upload to the web root of an account on the server through ftp/sftp
Login to the server and run the following command: certbot certonly --manual --csr /path/to/external_csr.pem --preferred-challenges “dns”
That was it, although I had to add dns TXT records to complete the domain verification challenges, wait for those records to be active and then continue with the process. This was very quick because we use Route53 and the default TTL for most record types is 300 seconds.
The following files were saved to root’s home directory (where I can the command from):
-rw-r–r-- 1 root root 1809 Jul 17 18:37 0000_cert.pem
-rw-r–r-- 1 root root 1647 Jul 17 18:37 0000_chain.pem
-rw-r–r-- 1 root root 3456 Jul 17 18:37 0001_chain.pem
I am not sure if it was necessary to specify the dns challenges because the domain for which this SSL was being generated for Akamai already had an LE cert on the server, so may be it was unnecessary?
Also, it can be seen that I didn’t specify the domain flag at all (-d ourdomain.com -d www.ourdomain.com) because that was already part of the external CSR, anyway.
Many thanks to @ahaw021, without whose help with the CSR command, I would have been quite lost. It would be a good idea for certbot to include the --csr command example in the documentation/manual.
