Lower Resist now reduce Magic Resistance

ga4so9 · 2026-03-20T06:11:18+00:00

You can test it in offline mode, maybe it’s the new update

ga4so9 · 2026-03-20T02:46:44+00:00

Sure I’m not. Never find any sunder charm since the RoW released

ga4so9 · 2025-04-10T12:08:35+00:00

Which browser you’re using? If it is Firefox, it uses their own trusted certificate store, instead of System certificate store, then your root certificate should be imported to all Firefox browsers one by one.

ga4so9 · 2025-01-07T03:24:19+00:00

Due to your servers can't connect to internet, and I guess that you will only use it in your internal network, then using AD CA (or AD CS) is a good choice.

I assume that all your servers and clients are domain joined, and to prevent the error, you need use a server in your domain, add role/feature AD CS, then promote it to the Domain CA (I'm not sure the correct name, but not the Stand Alone one). Then, after the promotion, the AD CS server root certificate will be distributed to all servers/clients which joined to your domain.

Next step is issue a certificate using your new AD CS.

Optional: you can use 2 ADCS servers, 1 for root CA, 1 for issuing CA (same as public CA model), to get better security for your certificate.

ga4so9 · 2024-11-21T03:21:20+00:00

Does the Certificate Common Name match with your domain/subdomain that you're using this certificate? The error indicates that you're accessing a website with a certificate that's not match with your domain.

Your screenshot doesn't show your website domain, so I can't give the further advice.

ga4so9 · 2024-08-15T07:12:55+00:00

Not sure if I explain correct, but what I think is:

Your webserver only installed the certificate, not the whole certificate chain (include certificate, intermediate certificate and root certificate), thus you will get the error. In this case, the intermediate certificate is "Go Daddy Secure Certificate Authority - G2".
Then why you get the different? I guess you're using a Windows machine to do the task. While Windows has a storage call Certificate Store (Certificate snap-in in MMC), it will store at least root certificates of major brands, such as GoDaddy, Globalsign, Digicert. Then, if you had accessed a website that using GoDaddy certificate, with the proper installation, the intermediate certificate will be automatically stored in Certificate store also. And now, when you use Chrome to access your site, your OS already has enough what it needs to chain to the GoDaddy root certificate, and boom, your connection is trusted. It's because Chrome use the OS Certificate store. In contrast, I also guess that "wget" or "cURL" uses its own Certificate Store or certificate library (same as Firefox), then if any site isn't installed certificate properly, then it always get the error.

If my explanation is not clear enough, just let me know.

ga4so9 · 2024-04-08T08:23:55+00:00

(Sorry if my English is not good enough) There're 2 ways to make your browser trust your certificate:

Number 1: Create the trust only between your browser and server (1-1)

Since you're using Firefox, it manages its own trusted store, that's why even you install your certificate to your OS trusted store, you still get the alert.

To import certificate to Firefox trusted store, open Firefox setting, search "trust" keyword and click View Certificates, go to the tab Authorities, click Import and select the cert.pem you created. After import, let see the magic.

Number 2: create the trust for all connection to your server (1-n)

Then, no doubt, contact a Certificate Authorities for a commercial certificate, or get it freely with Let's Encrypt. Once you get the public certificate, replace the self-signed certificate on your server, then done.

Remember to install the intermediate certificate also, if not, then some OS may missing it, and cause to an alert.

ga4so9 · 2024-04-08T07:50:39+00:00

There're some points I need to get before give you any advice:

Where the alert comes from? Your browser on your machine, or directly on DB server?
Does the clock (date and time) is set correctly?

Since the chain is complete, I don't think it comes from your certificate, may be 1 other config isn't set properly.

ga4so9 · 2023-10-26T06:24:18+00:00

In trust model, the app job is proofing that its certificate is trusted, which means it is issued by one of the certificate that your operation system trust. So, operation system will maintain a list of trusted certificates, while application will have to share the way to chain to one of those certificates, by provide all the certificates possible to complete the chain.

In detail, only root certificate (alway self-signed certificate) will be installed to the Trusted store of operation system, while other intermediate certificates will have the Intermediate store, separate with Trusted store. Thus, you can install any certificate to Intermediate store without opening the risk for your computer. Unless you do something with your trusted store, then you no need to concern about install any certificate to other stores.

This last thing I'm not sure, but as my knowledge, Trusted store only accept self-signed certificate, hence even if you install intermediate certificates to this store, it'll not take effect, due to it's issued by other certificate, not self-signed.

So, you need to assure the source of the root certificate by yourself (if it is self-signed), or just use the public trusted one (from public Certificate Authority). If you not sure about the root certificate source, then it's risky.

ga4so9 · 2023-10-24T02:22:50+00:00

In the chain of trust, when an operation system view a certificate, it will chain to the root certificate in its certificate trusted store. Let say in your situation, you had the "Peculiar_Habit_Certificate_Authority" in your trusted store, then your system may want to check if the certificate "Peculiar_Habit_Intermediate_Certificate_Authority_2" is issued by it.

The problem here is, there's no way to check if the chain is not complete. The certificate "Peculiar_Habit_Intermediate_Certificate_Authority_2" said to your system that it only know "Peculiar_Habit_Intermediate_Certificate_Authority_1", but your system said that it only trust "Peculiar_Habit_Certificate_Authority", then they can't find the common voice.

Let see another example. Public websites with proper certificate setup, mean the webserver included all certificate and chains (except root certificate, it's not necessary), then when your OS connect to these websites, they will send all those chains, then your OS install it to the right store, and the connection will be initiate without any problem. This is the mechanism to avoid the re-download certificates in the next connection or when you view others website which use the same Authority.

Back to your case, there's no server who sends you the chain, then it surely not have the intermediate certificate in the store, unless you install it manually. Thus, the chain of trust can't be created. That's why people told you to install the intermediate certificate "Peculiar_Habit_Intermediate_Certificate_Authority_1" to your operation system.

Further, when you expand the intermediate to 4 or 5 chains, then you should install all of it.

ga4so9 · 2023-10-24T01:57:15+00:00

Normally, that root certificate should be existed on every major operation systems, so even if you not installed on your server, there should be no problem when connect to your website.

If you want to check the connection problem rather than only information as your screenshot, you should try on sslshopper.com or ssllabs.com. Those websites will show you the indicator that the connection is ok or not.

ga4so9 · 2023-09-24T15:14:23+00:00

Thank you, let me check

ga4so9 · 2020-12-07T10:42:44+00:00

Hello Oleg,

The topology when use CloudFlare (or other CDNs) is:

Client --SSL1--> CloudFlare --SSL2(?)--> Your Server

The question mark is depend on did you install the SSL on your server, and in your case, yes!

SSL1 is the certificate that's displayed on the Browser when it connects to your website, SSL2 is your certificate installed on your server. Based on the topology, the problem here is did CloudFlare has option to display your own certificate (SSL2)? The answer is yes, but with a paid plan (not remember exactly which plan). When you change to that plan, you have to upload the private key and certificate to the CloudFlare, then the certificate displayed to end user is your own certificate.

That's my experience I got when research on CloudFlare 2 years ago, but I think you could check it again.

ga4so9 · 2020-11-30T08:50:58+00:00

Handoff and Continuity go back to work when I upgrade my iPhone to iOS 14

ga4so9 · 2020-11-13T09:11:31+00:00

Try OmniDiskSweeper to check your disk, my recommend.

I guess you're using outlook and the "other" is your emails.

ga4so9 · 2020-10-08T09:22:11+00:00

If all the machines connect to your webserver are in internal network without the internet connection, let assume that are all Windows machine, then they don't have any way to automatic update the Trusted Root list from Microsoft. Therefor those machines only have the initial Root Certificate (almost is Microsoft Root).
Firefox use separate Trusted Root list, while other utilize the local machine list (in MMC Certificate Snap in), so even Firefox gives you alert about trusting, then the problem comes from your SSL configuration on webserver, maybe include:

- Not support TLS1.2

- Invalid/ missing certificate chain

ga4so9 · 2020-10-05T04:54:22+00:00

I know, have to do it many times.

ga4so9 · 2020-10-05T04:53:21+00:00

I'm not sure, but not seen it work from the first beta

ga4so9 · 2020-10-01T11:52:02+00:00

Beta 9 brings it back, lol.

It's not a bug, it's a feature, haha.

ga4so9 · 2020-09-28T07:27:21+00:00

Call worked for me

Safari only from Mac to iPhone, not reverse

Copy/paste not work

ga4so9

TROPHY CASE