Hello all,
I need to get some SSL certificates for some african country operations and i can unfortunately not use letsencrypt for this. I was trying to get a certificate from Swissign for this but for some reason they refuse issuing certificates to domains for Guinea and Guinea Bissau because these countries are on their embargo TLD list. It is known that some individuals from these countries are on a UN embargo list, but thats also true for some people from Germany or Switzerland or USA. And these countries are not blocked. In other words, I need another certificate provider, preferrably not under US control (so not Comodo, Digicert, Thawte, Symantec, Verisign etc), who can issue multidomain certificates for .gw, .com.gn, .sl, .io, .com domains.
Anyone have a good hint?
Hi Andreas
These two countries are not currently under comprehensive US sanctions:
https://home.treasury.gov/policy-issues/financial-sanctions/sanctions-progra...
So any CA, except, it seems SwissSign, should do.
Best Serge
On 13.05.21 11:29, Andreas Fink wrote:
Hello all,
I need to get some SSL certificates for some african country operations and i can unfortunately not use letsencrypt for this. I was trying to get a certificate from Swissign for this but for some reason they refuse issuing certificates to domains for Guinea and Guinea Bissau because these countries are on their embargo TLD list. It is known that some individuals from these countries are on a UN embargo list, but thats also true for some people from Germany or Switzerland or USA. And these countries are not blocked. In other words, I need another certificate provider, preferrably not under US control (so not Comodo, Digicert, Thawte, Symantec, Verisign etc), who can issue multidomain certificates for .gw, .com.gn, .sl, .io, .com domains.
Anyone have a good hint?
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
-- Dr. Serge Droz Senior Security Engineer
Serge Droz wrote on 13.05.21 10:02:
Hi Andreas
These two countries are not currently under comprehensive US sanctions:
https://home.treasury.gov/policy-issues/financial-sanctions/sanctions-progra...
So any CA, except, it seems SwissSign, should do.
Best Serge
Any "CA" which is not owned by a US controlled entity was the target.
I find it rather sad that a swiss (=neutral) SSL certificate provider owned by the Swiss Post which is in turn owned by the Swiss Government sanctions by themselves countires just because they are afraid that a drug smuggler could buy a domain... But thats a rant for another day... Banks are not too big to fail anymore. They are destined to fail (Keyword: advance obedience).
Andreas Fink
On 2021-05-13 11:29, Andreas Fink wrote:
Hello all,
I need to get some SSL certificates for some african country operations and i can unfortunately not use letsencrypt for this.
Any reason? What are your requirements?
Would ZeroSSL (https://zerossl.com) who also do ACME work?
(yes people, Let's Encrypt is not the only game... if you do ACME for your systems, also setup zero ssl and issue certs from both places at the same time, just in case LE ever has an issue, though that will be resolved rather quickly with 72% marketshare (https://ct.cloudflare.com)
I was trying to get a certificate from Swissign for this but for some reason they refuse issuing certificates to domains for Guinea and Guinea Bissau
Do you need org validated or something that the country matters?
Greets, Jeroen
Jeroen Massar wrote on 13.05.21 10:46:
On 2021-05-13 11:29, Andreas Fink wrote:
Hello all,
I need to get some SSL certificates for some african country operations and i can unfortunately not use letsencrypt for this.
Any reason? What are your requirements?
the mailserver I use, does not support ACME setup. I can only do old style SSL certificate requests. for the webserver its not an issue though.
Would ZeroSSL (https://zerossl.com) who also do ACME work?
No. ACME is the issue. And ZeroSSL is hosted in the US on cloudflare with a cloudflare SSL certificate. So by definition not DSGVO conform as NSA could theoretially infiltrate cloudflare to infliltrate all my certs etc. etc. It might be far fetched but since snowden, we know that many things we considered far far far fetched are not anymore.
(yes people, Let's Encrypt is not the only game... if you do ACME for your systems, also setup zero ssl and issue certs from both places at the same time, just in case LE ever has an issue, though that will be resolved rather quickly with 72% marketshare (https://ct.cloudflare.com)
Cloudflare's juristiction is definitively a red flag for me.
I was trying to get a certificate from Swissign for this but for some reason they refuse issuing certificates to domains for Guinea and Guinea Bissau
Do you need org validated or something that the country matters?
no. I simply need the domain be in that country. The holder of the domain can be myself in switzerland or one of the entities in Africa which is not on the blacklist (which is actually what I tried). Swisssign put the certificate under embargo because the domain ending contained .gw and .com.gn. Thats all. And I don't want to buy a domain for every mailserver separately, thats why I want a multidomain certificate. As it has to be renewed every years its painfully enough already.
On 2021-05-13 13:05, Andreas Fink wrote:
Jeroen Massar wrote on 13.05.21 10:46:
On 2021-05-13 11:29, Andreas Fink wrote:
Hello all,
I need to get some SSL certificates for some african country operations and i can unfortunately not use letsencrypt for this.
Any reason? What are your requirements?
the mailserver I use, does not support ACME setup. I can only do old style SSL certificate requests. for the webserver its not an issue though.
You could get the certs from LE/ZeroSSL every 90 days and replace them by hand.... does not scale, but works ;)
But there are thousands of CAs, just check the list.
Would ZeroSSL (https://zerossl.com) who also do ACME work?
No. ACME is the issue. And ZeroSSL is hosted in the US on cloudflare with a cloudflare SSL certificate. So by definition not DSGVO conform as NSA could theoretially infiltrate cloudflare to infliltrate all my certs etc. etc. It might be far fetched but since snowden, we know that many things we considered far far far fetched are not anymore.
You have the private key and that does not leave the box unless you do that, thus unless there is some crypto that is broken, they can't do much with that. If they have broken crypto some way, then it applies to everything and we are generally screwed. I am not aware of such a thing at this point in time.
All certs are logged in Certificate Transparency (see for instance https://ct.cloudflare.com/) thus the source should not matter.
The US unfortunately is where most corporations&monopolies are based; companies in the rest of the world fall under bilateral exchange laws.
Thus if one is afraid of the US, it is game over, one will have to disconnect from this Internet thing as their influence (code/hardware/legal/people) is everywhere.
For me at least that is not a threat, your model might include it it seems.
You more have to be afraid of the Googles of the world, considering they control the browser trust store: https://thehackernews.com/2017/07/chrome-certificate-authority.html as a quick random example...
(yes people, Let's Encrypt is not the only game... if you do ACME for your systems, also setup zero ssl and issue certs from both places at the same time, just in case LE ever has an issue, though that will be resolved rather quickly with 72% marketshare (https://ct.cloudflare.com)
Cloudflare's juristiction is definitively a red flag for me.
As above, I'll give a little link: https://www.coe.int/en/web/criminal-law-coop/bilateral-cooperation
US law is enforced everywhere, we (.ch) fortunately/hopefully have judges that protect from overreach though.
I was trying to get a certificate from Swissign for this but for some reason they refuse issuing certificates to domains for Guinea and Guinea Bissau
Do you need org validated or something that the country matters?
no. I simply need the domain be in that country. The holder of the domain can be myself in switzerland or one of the entities in Africa which is not on the blacklist (which is actually what I tried). Swisssign put the certificate under embargo because the domain ending contained .gw and .com.gn. Thats all. And I don't want to buy a domain for every mailserver separately, thats why I want a multidomain certificate. As it has to be renewed every years its painfully enough already.
Sounds like upgrading software or fronting it with a proxy is the way to go, as then you can do like the rest of the world (well 72%): LE....
An alternative option would be to use DANE/TSLA, then you can provide a self-signed certificate. Watch out with setting up MTA-STS in that case though.
At that point though, you already have new software that should be able to handle ACME certificates (read: being able to reconfigure the SSL cert in a scripted manner).
Greets, Jeroen
PS: Don't hesitate to provide details of the setup off-list and we can see what we can do if you want to go the LE route.
On 13.05.2021 13:05, Andreas Fink wrote:
(yes people, Let's Encrypt is not the only game... if you do ACME for your systems, also setup zero ssl and issue certs from both places at the same time, just in case LE ever has an issue, though that will be resolved rather quickly with 72% marketshare (https://ct.cloudflare.com)
Cloudflare's juristiction is definitively a red flag for me.
Cloudflare is a good idea, but the service is a direct Drill into the security, as they are man in the middle decrypting ssl in there network and crypt again on the exitpoint
all those CA's are even a security Risk, doesn't matter how big the promisses are ;)
back to your ACME problem, what i have done setup nginx and let letsencrypt do the job and then used the files, a simple copy job copy them over
if it comes just to webmail and SSL use an nginx as proxy doing the job .. encrypted from the client to the frontend (nginx) then plain to the backend
just my 5 cent ... Roger
Hello Andreas
On 13.05.2021 13:05, Andreas Fink wrote:
Jeroen Massar wrote on 13.05.21 10:46:
On 2021-05-13 11:29, Andreas Fink wrote:
Hello all,
I need to get some SSL certificates for some african country operations and i can unfortunately not use letsencrypt for this.
Any reason? What are your requirements?
the mailserver I use, does not support ACME setup. I can only do old style SSL certificate requests. for the webserver its not an issue though.
I am using LEGO [1] for ACME with DNS, so none of the servers need to support ACME. I am using it with an own dedicated dynamic sub-zone through RFC2136, but there is also a large selection of DNS providers to choose from (if the domains are hosted there). From the FreeBSD Ports [2] I got lego.sh (which I had to modify a little bit for DNS), which does weekly checks through periodic. For the also needed deploy.sh I wrote my own doing a copy of the new certificates into an timestamped directory and sending me an email with instructions on how to run a third script for doing all the distribution for that certain certificate, which then does copy (scp) the new certificates to the systems / services needed, and also restart services. Something I do not wanted to do unattended.
[1] https://github.com/go-acme/lego [2] https://cgit.freebsd.org/ports/tree/security/lego
Would ZeroSSL (https://zerossl.com) who also do ACME work?
No. ACME is the issue. And ZeroSSL is hosted in the US on cloudflare with a cloudflare SSL certificate. So by definition not DSGVO conform as NSA could theoretially infiltrate cloudflare to infliltrate all my certs etc. etc. It might be far fetched but since snowden, we know that many things we considered far far far fetched are not anymore.
As Jeroen already mention, the private key of the certificate is always in your own possession, if you are doing it right. At least a long time ago the already mention domestic CA did create a private key for you, if you did not supply a CSR (certificate signing request) during the process, this may have changed. LEGO (or probably any other ACME client), does create a local private key and CSR on your own system. Then only the CSR is sent to the CA, and the CA will sign this with their private key and return the certificate back to you. If the certificate does not match with the key, it will not work and clients will report an error as they are unable to decrypt the content which was encrypted from your private key.
So in general I do not see any problems regarding GDPR with using any CA (even in the US). But there are more things which could be done to get a better privacy for the user visiting your sites. As currently browser are doing OCSP (Online Certificate Status Protocol) request back to the issuing CA on each visit to your site, you should also look into implement OCSP Stapling. Your site will regularly fetch this OCSP answers (they are valid for quite a while) from the CA, and then return them to the client browser on first visit.
PS: Also consider to set CAA entries in DNS to only allow your chosen CA to create certificates for you.
Best regards, Fabian
the mailserver I use, does not support ACME setup. I can only do old style SSL certificate requests. for the webserver its not an issue though.
Why does the mail server need to support ACME?
Simply do periodic DNS verification and trigger a restart/reload of the internet-facing mail server components when the certificate was renewed.
And if replacing the cert in your mail service requires manual action, you could disable SSL and put a TCP load balancer that does SSL offloading in front of it.
With the maximum validity period of certificates supported by browsers getting shorter and shorter, you'll eventually have to deal with fully automated certificate renewal anyway.
Even some "traditional" cert providers have understood this and provide ACME or ACME-like renewal functionality: https://docs.digicert.com/certificate-tools/Certificate-lifecycle-automation...
On 2021-05-20 08:51, Gregor Riepl wrote:
the mailserver I use, does not support ACME setup. I can only do old style SSL certificate requests. for the webserver its not an issue though.
Why does the mail server need to support ACME?
Simply do periodic DNS verification and trigger a restart/reload of the internet-facing mail server components when the certificate was renewed.
And if replacing the cert in your mail service requires manual action, you could disable SSL and put a TCP load balancer that does SSL offloading in front of it.
For SMTPS (TLS tcp/465) yes, but most inbound mail goes over plain 25 and then does the EHLO/STARTTLS dance, thus one does then need a load balancer that understand that AND that then also passes the right IP address to the backend if the real mail server does anything with an IP address. Transparent TCP/STARTTLS interception is.... fun ;)
Also, outbound mail goes over TLS / STARTTLS and one can even indicate that with MTA-STS. (https://www.hardenize.com/blog/mta-sts has a good intro on MTA-STS).
And that means outbound mail needs to properly do SSL too.
Upgrading to a mail system from >2015 is thus a much better idea ;)
With the maximum validity period of certificates supported by browsers getting shorter and shorter, you'll eventually have to deal with fully automated certificate renewal anyway.
Even some "traditional" cert providers have understood this and provide ACME or ACME-like renewal functionality: https://docs.digicert.com/certificate-tools/Certificate-lifecycle-automation...
Indeed, they are wising up that otherwise their business model croacks.
Which is evidenent with 70%+ market share for Let's Encrypt.
I still find it funny that Digicert allows "Org Validated" (OV) certs to be issued there. That is one of the few business cases that is left (e.g for bare IP SSL certificates)
Greets, Jeroen
I still find it funny that Digicert allows "Org Validated" (OV) certs to be issued there. That is one of the few business cases that is left (e.g for bare IP SSL certificates)
And it may make sense for S/MIME certs (even though „LE for S/MIME“ is on the horizon, see RFC 8823).
— Matthias
Greets, Jeroen
swinog mailing list swinog@lists.swinog.ch http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
-
Andreas Fink -
Fabian Wenk -
Gregor Riepl -
Jeroen Massar -
Matthias Leisi -
Roger -
Serge Droz