# Trust of sslforfree.com to generate private keys **URL:** \ **Category:** Client dev\ **Created:** [September 20, 2018, 8:39pm UTC](https://community.letsencrypt.org/t/trust-of-sslforfree-com-to-generate-private-keys/72779 "2018-09-20T20:39:55Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![tdelmas](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tdelmas/32/1866_2.png) [@tdelmas](https://community.letsencrypt.org/u/tdelmas)\ **Post date:** [September 20, 2018, 8:39pm UTC](https://community.letsencrypt.org/t/trust-of-sslforfree-com-to-generate-private-keys/72779/1 "2018-09-20T20:39:55Z")
WARNING - EDIT nov-2020 : some services mentioned have significantly changed. **Advice may not be up to date!** Two older threads asked if it was secure to use it: > [@Is this safe? (sslforfree.com)](https://community.letsencrypt.org/t/is-this-safe-sslforfree-com/54354): > > I… > [@About sslforfree.com?](https://community.letsencrypt.org/t/about-sslforfree-com/23515): > > H… On both, the advice was to prefer [https://gethttpsforfree.com/](https://gethttpsforfree.com/) (who doesn't generate private keys) but without details. One suggested [zerossl.com](https://zerossl.com/free-ssl/#crt) (who also generate private keys) **As a general advice, it's better to generate your private key and csr offline.** If you must generate it online you have to trust the service. I see some red flags about sslforfree: - there is no information on who is running that website on the webpage and the only contact link is an anonymous email ( [info@sslforfree.com](mailto:info@sslforfree.com) ) - the whois is anonymized - the commit to add it on the [ACME Client Implementations - Let's Encrypt](https://letsencrypt.org/docs/client-options/) webpage, [Add sslforfree to client-options.md (#127) · letsencrypt/website@8b2540b · GitHub](https://github.com/letsencrypt/website/commit/8b2540bbdc04ee9f1503e31a3785d4e28f240616) doesn't seams to be done by them and the PR behind it is private or deleted: [https://github.com/letsencrypt/website/pull/127](https://github.com/letsencrypt/website/pull/127) - the only clue I found was in [Show HN: Free SSL Certificates | Hacker News](https://news.ycombinator.com/item?id=10741148) where the user [etrackr](https://news.ycombinator.com/user?id=etrackr) seams to be the author of that website And, from a security point of view: - HSTS: No HSTS ( so no HSTS preload [HSTS Preload List Submission](https://hstspreload.org/?domain=sslforfree.com) ) - Headers: No Content-Security-Policy, X-XSS-Protection, X-Content-Type-Options: [Mozilla Observatory](https://observatory.mozilla.org/analyze/www.sslforfree.com) / [Scan results for www.sslforfree.com](https://securityheaders.com/?followRedirects=on&hide=on&q=www.sslforfree.com) - Bad https configuration: [SSL Server Test: www.sslforfree.com (Powered by Qualys SSL Labs)](https://www.ssllabs.com/ssltest/analyze?d=www.sslforfree.com) - Load externals javascript (and without SRI) **So I would not recommend that website to generate your private key.** ~~Although it should be safe to use to generate a certificate if you already have a CSR~~ (See [#2](https://community.letsencrypt.org/t/trust-of-sslforfree-com-to-generate-private-keys/72779/2)) Beware, that service also may ask for your ftp password: ![image](https://global.discourse-cdn.com/letsencrypt/original/3X/1/e/1e5c8333ef0cab99e8ecc9418c1d2d50be78fd62.png) Site note: Let's Encrypt apparently decided to stop listing browser based clients on [ACME Client Implementations - Let's Encrypt](https://letsencrypt.org/docs/client-options/) : [client-options: document inclusion/update policy. by cpu · Pull Request #377 · letsencrypt/website · GitHub](https://github.com/letsencrypt/website/pull/377) To compare with [Free SSL Certificates and SSL Tools - ZeroSSL](https://zerossl.com/free-ssl/#crt) : - Contact info are accessible: [About - ZeroSSL](https://zerossl.com/about.html) - No external javascript loaded - HSTS and preloaded: [HSTS Preload List Submission](https://hstspreload.org/?domain=zerossl.com) - Most security headers (sadly, no CSP nor SRI) : [Mozilla Observatory](https://observatory.mozilla.org/analyze/zerossl.com) - Robust https configuration: [Mozilla Observatory](https://observatory.mozilla.org/analyze/zerossl.com#tab-third-party-tests) ---
**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\ **Post date:** [September 20, 2018, 9:29pm UTC](https://community.letsencrypt.org/t/trust-of-sslforfree-com-to-generate-private-keys/72779/2 "2018-09-20T21:29:56Z")
> [@tdelmas](#): > > **Although it should be safe to use to generate a certificate if you already have a CSR** This isn't really safe either. Due to the fact that authorizations are re-usable (currently for 30 days), it opens the opportunity for [sslforfree.com](http://sslforfree.com) to just silently\* issue an identical certificate under an alternate private key. This is because they control the ACME account key at all times. (\* mitigated by CT logs but most users are not savvy to that) ---
**Author:** ![tdelmas](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tdelmas/32/1866_2.png) [@tdelmas](https://community.letsencrypt.org/u/tdelmas)\ **Post date:** [September 20, 2018, 9:36pm UTC](https://community.letsencrypt.org/t/trust-of-sslforfree-com-to-generate-private-keys/72779/3 "2018-09-20T21:36:06Z")
> [@\_az](#): > > This isn’t really safe either. Due to the fact that authorizations are re-usable Thanks for pointing that out, corrected! ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [October 20, 2018, 9:36pm UTC](https://community.letsencrypt.org/t/trust-of-sslforfree-com-to-generate-private-keys/72779/4 "2018-10-20T21:36:07Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.