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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
Welcome to the Let's Encrypt Community, @Taofiq331!
I'm the author of CertSage. As @orangepizza has correctly indicated, another CertSage user (along with myself) ran into the same problem recently. Please try the certsage.txt in the following post to see if it resolves the problem for you:
I will probably need to release a new version of CertSage soon making the minor tweak in that post permanent if CertSage users continue seeing the same problem. I might do that today in fact.
I tried it again later and it worked well except for www.hubaya.com which keep giving error code 500.
I also noticed that when i tried the website on old browsers, it still says not safe as if the certificate is invalid but it works well on new version of browsers.
The last problem is that when i try to make a request from my phone android version 7 to an api endpoint on the website, it fails to give reply because of ssl certificate. The apps linked to this website are down. Is it because of my phone is old or the ssl certificate has a limitation?
And if im the one missing something please guide me on how to fix it.
Also thank you for welcoming me to the community. Im grateful.
I really appreciate the time you gave me.
I have no more problem with pay.hubaya.com and im now having problem with only www.hubaya.com as it is giving me 500 error code. But it works fine with www.pay.hubaya.com.
pay.hubaya.com is a subdomain of hubaya.com.
I have also gone through the thread you share about older android phones and its advised for older android version users to switch to Mozilla Firefox browser nd not any change in the certificate will amend the problem.
The problem now is how can i generate ssl for www.hubaya.com and also the older android version issue if there is another fix to it.
Indeed hubaya.com and www.hubaya.com point to different IP addresses that appear to possibly be being served by different softwares. Per industry standards, I would expect http://hubaya.com to be redirected to https://hubaya.com then redirected again to https://www.hubaya.com.
When visiting https://www.hubaya.com/ it looks like there is some kind of redirect/masking/rewrite to https://hubaya.com/ . That's not a concern per se, just unexpected to me. I personally use the non-www domain name for my sites, so this route is alright to me, but obviously getting the 500 working is paramount. Let me check further...
It is failing probably because the IP isn't the same. Usually the www subdomain points to the same IP as its base name. I asked before but why does it point somewhere else?
You could use a different (free) ACME Certificate Authority if you need to support older Androids. You would have to check which ones support the devices you care about
Yeah, I was pretty sure it was some sort of URL Redirect service. They just need to disable that and point directly to their public IP like they do with their other names.
I completely concur. Using an actual HTTP redirect from www.hubaya.com to hubaya.com rather than the masking should resolve the issue and greatly simplify the system.
I suspect that you're trying to use hubaya.com as your primary domain name and redirect www.hubaya.com to it. If you are intending to do the opposite, adjustments need to be made. As long as you know which way you intend, adjusting accordingly (and removing the masking) should be relatively straightforward. You should do this regardless of whom you use as a certificate provider.
Same for www.hubaya.com but i just changed my hosting to shared hosting and i think there might have been some mistakes in the process. I will contact my hosting provider for them to rectify this issue.
I will also try other versions of ACME to see if there is any one that best suit me.
Another thing is that im using certsage and not certbot and i can't find other versions of certsage to use to get the certificate that will make the website accessible by older browsers and olded phone.
Please take a look into that URL redirect. It should be a standard redirect (301).
Like certbot, CertSage is just an ACME client that interacts with a certificate authority's (CA's) ACME API. In the case of CertSage, the default CA is Let's Encrypt. The distribution of root certificates for any particular CA are controlled by the root programs of operating systems and browsers with the CA having limited influence on those root programs. No ACME client can influence support of a CA's certificates in terms of backward compatibility, aside from things like key-type support (e.g. RSA, ECDSA). Thus, it all comes down to the CA.
But that is also the only CA supported by CertSage - right?
I think @Taofiq331 was reacting to my earlier comment about using a different CA. I was replying to his comment shown below. Not sure if CertSage is the only viable ACME Client on their system. Was just pointing out another option than Firefox they already saw.
Not per se. Theoretically, one can simply change the ACME directory URLs on lines 361 and 368 of CertSage version 1.4.1 to point to any ACME CA's directory URLs. Granted, I've never tried doing so and there might be idiosyncrasies of Let's Encrypt unintentionally baked into CertSage's processes.
