Renew SSL at namecheap

Help
1

Hi.

I recently transferred my hosting to namecheap and unfortunately I have just found out they "force" you to buy their paid for SSL.
The thing is my old hosting had automatically provided SSL via Let's Encrypt (that will expire in a couple of weeks).
Now I just want to renew the SSL that I have via Let's Encrypt because I don't want to have the namecheap "embedded" SSL. Is there an easy way to renew vs fresh install?

Thanks

2 Likes
2

Welcome to the Let's Encrypt Community :slightly_smiling_face:

Do you have root access to your hosting account? If so, try using certbot. If not, you can use this:

There is no difference whatsoever between a "renewed" certificate and a new certificate.

3 Likes
4

I've ran certsage.php and acquired production certificate and went well.
Now I can't find the certsage folder as per the instructions.
Thanks

3 Likes
5

OOPS. Sorry.
It's all OK now.
Thank you so very much!!!
One final question: will I have to do this every 3 months? Or is there a way to automatically renew the certificate?

3 Likes
7

That is controlled/limited by the Hosting Service Provider (HSP) [not LE, nor CertSage]

3 Likes
8

At present you will need to repeat the process every 60-90 days. In an upcoming release, I am planning to add some architectural extensions to CertSage so that it can also be run from the command line, which will allow the use of automation methods (like crontabs and such) to run CertSage periodically to acquire new certificates. As long as certificate installation can be automated as well (automatic cPanel installation is coming soon too), that will often make fully automated renewals possible, even with the most uncooperative of hosting service providers.

4 Likes
9

Think also about cron running on other machines, like if I put something to run

curl -qL http://example.com/CertSage.php?cron

several times a week on some random machine.

5 Likes
10

That's an interesting thought, @9peppe. :thinking:

It kinda turns CertSage into a rest-ish app. At present the parameters are POST and not GET though. Definitely interesting...

5 Likes
11

It is a neat idea and it does kinda. Make sure you add some sort of auth-key to avoid becoming a vector for bots :slight_smile:

6 Likes
12

I'd stick with POST, GET is logged and in some environments that would mean the auth key (which you'd definitely need) would be in the log file, which you perhaps don't control.

6 Likes
13

So @rg305, to make sure I understand you, if someone acquired a certificate using CertSage, it's the hosters job to renew that same certificate issued using CertSage? :question:

4 Likes
14

The ability to put anything in place that can allow/control autorenewals is managed by the HSP.
Especially in the cases where CertSage was the only choice left and had to be used [shared hosting].
I didn't say it was anyone's job to enable renewals.
What I said/meant was much is controlled by the HSP and one should talk with them about how best to enable autorenewals on their system [LE nor CertSage can do much in such cases].

3 Likes
15

Hopefully I can change that soon.

:crossed_fingers:

3 Likes
16

You probably don't need it. Just make sure that if you call it with ?cron it can do one thing and one thing only, and only if it hasn't done it in the last X hours.

2 Likes
17

Then I misunderstood the meaning of "controlled" in your post.

Indeed, there's not much wrong with a renewal triggered by an external user instead of a cron ran twice a day :slight_smile: (No sarcasm FYI.)

And with ARI an ACME client should be run even more frequent than twice a day!

That said, the above obviously depends on the load such a trigger would have on a system. If the load is minimal, i.e.: less than that of e.g. index.php for the main website, then it reaaally doesn't matter. Instead, if the cron part of CertSage impacts a significant load on the host, then it would be wise to limit access to it.

4 Likes
18

Http basic auth or an authorization token via either get or post like most dynamic DNS providers also work, but it might be a bit of a needless complication. That's why I said to only run the cron every X hours (and certsage should refuse to run it if the last run is more recent than X)

It's rendered moot if you call it over http, though

4 Likes
19

Or, if you want the extreme overkill and security over unencrypted http, you have to implement some kind of nonce against replay attacks

Kinda like

curl -qL http://example.com/certsage.php?nonce=$(cat next_nonce)&cron > next_nonce

(cat is probably not the right command)

4 Likes
20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.