how to make Gnu/Linux trust a certificate that's trusted by Windows out-of-the-box?
There is a server with a broken SSL chain, as reported by this SSL check:

I know this is a problem that should be solved on the server itself, but sometimes this is hard to have fixed (I'm not the admin of the server).
The thing is, that Chrome/Mozilla/Edge on Windows trust the site certificate anyway:

However, in a Gnu/Linux deployment (Ubuntu 18.04 in Docker) the certificate is not trusted:
curl: (60) SSL certificate problem: unable to get local issuer certificate
I tried update-ca-certificates and even imported the Globalsign Root certificate. update-ca-certificates reported a duplicate certificate in that case. Anyway, nothing works.
How to reproduce
Using Docker:
docker run -it ubuntu:18.04
# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it # <---- "unable to get local issuer certificate"
How can I make Gnu/Linux trust this certificate?
PS: The same certificate is deployed correctly on another server.
curl openssl ssl certificates
|
show 4 more comments
There is a server with a broken SSL chain, as reported by this SSL check:

I know this is a problem that should be solved on the server itself, but sometimes this is hard to have fixed (I'm not the admin of the server).
The thing is, that Chrome/Mozilla/Edge on Windows trust the site certificate anyway:

However, in a Gnu/Linux deployment (Ubuntu 18.04 in Docker) the certificate is not trusted:
curl: (60) SSL certificate problem: unable to get local issuer certificate
I tried update-ca-certificates and even imported the Globalsign Root certificate. update-ca-certificates reported a duplicate certificate in that case. Anyway, nothing works.
How to reproduce
Using Docker:
docker run -it ubuntu:18.04
# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it # <---- "unable to get local issuer certificate"
How can I make Gnu/Linux trust this certificate?
PS: The same certificate is deployed correctly on another server.
curl openssl ssl certificates
why the downvote?
– Udo G
2 hours ago
1
I'm voting to close this question as off-topic because the OP is asking something he can't influence himself. He said he can't modify anything server-side, so this probably belongs to superuser I think, as it describes a problem having no solution client-side.
– Vlastimil
2 hours ago
1
I am specifically asking for a client-side solution. I can't influence the server, but I have full control over the client O/S (Ubuntu) and I want this specific O/S installation to trust the certificate just like other O/S (Windows) do. It's not about fixing the HTTPS site for others.
– Udo G
1 hour ago
That is exactly why I believe it is off-topic here. I'm off to go, see you.
– Vlastimil
1 hour ago
The question is about using/administering a *nix system and applications packaged therein
– Udo G
1 hour ago
|
show 4 more comments
There is a server with a broken SSL chain, as reported by this SSL check:

I know this is a problem that should be solved on the server itself, but sometimes this is hard to have fixed (I'm not the admin of the server).
The thing is, that Chrome/Mozilla/Edge on Windows trust the site certificate anyway:

However, in a Gnu/Linux deployment (Ubuntu 18.04 in Docker) the certificate is not trusted:
curl: (60) SSL certificate problem: unable to get local issuer certificate
I tried update-ca-certificates and even imported the Globalsign Root certificate. update-ca-certificates reported a duplicate certificate in that case. Anyway, nothing works.
How to reproduce
Using Docker:
docker run -it ubuntu:18.04
# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it # <---- "unable to get local issuer certificate"
How can I make Gnu/Linux trust this certificate?
PS: The same certificate is deployed correctly on another server.
curl openssl ssl certificates
There is a server with a broken SSL chain, as reported by this SSL check:

I know this is a problem that should be solved on the server itself, but sometimes this is hard to have fixed (I'm not the admin of the server).
The thing is, that Chrome/Mozilla/Edge on Windows trust the site certificate anyway:

However, in a Gnu/Linux deployment (Ubuntu 18.04 in Docker) the certificate is not trusted:
curl: (60) SSL certificate problem: unable to get local issuer certificate
I tried update-ca-certificates and even imported the Globalsign Root certificate. update-ca-certificates reported a duplicate certificate in that case. Anyway, nothing works.
How to reproduce
Using Docker:
docker run -it ubuntu:18.04
# within container:
apt-get update
apt-get -y install curl
curl https://betriebsheft.vog.it # <---- "unable to get local issuer certificate"
How can I make Gnu/Linux trust this certificate?
PS: The same certificate is deployed correctly on another server.
curl openssl ssl certificates
curl openssl ssl certificates
edited 4 mins ago
ctrl-alt-delor
10.6k41955
10.6k41955
asked 2 hours ago
Udo G
4862522
4862522
why the downvote?
– Udo G
2 hours ago
1
I'm voting to close this question as off-topic because the OP is asking something he can't influence himself. He said he can't modify anything server-side, so this probably belongs to superuser I think, as it describes a problem having no solution client-side.
– Vlastimil
2 hours ago
1
I am specifically asking for a client-side solution. I can't influence the server, but I have full control over the client O/S (Ubuntu) and I want this specific O/S installation to trust the certificate just like other O/S (Windows) do. It's not about fixing the HTTPS site for others.
– Udo G
1 hour ago
That is exactly why I believe it is off-topic here. I'm off to go, see you.
– Vlastimil
1 hour ago
The question is about using/administering a *nix system and applications packaged therein
– Udo G
1 hour ago
|
show 4 more comments
why the downvote?
– Udo G
2 hours ago
1
I'm voting to close this question as off-topic because the OP is asking something he can't influence himself. He said he can't modify anything server-side, so this probably belongs to superuser I think, as it describes a problem having no solution client-side.
– Vlastimil
2 hours ago
1
I am specifically asking for a client-side solution. I can't influence the server, but I have full control over the client O/S (Ubuntu) and I want this specific O/S installation to trust the certificate just like other O/S (Windows) do. It's not about fixing the HTTPS site for others.
– Udo G
1 hour ago
That is exactly why I believe it is off-topic here. I'm off to go, see you.
– Vlastimil
1 hour ago
The question is about using/administering a *nix system and applications packaged therein
– Udo G
1 hour ago
why the downvote?
– Udo G
2 hours ago
why the downvote?
– Udo G
2 hours ago
1
1
I'm voting to close this question as off-topic because the OP is asking something he can't influence himself. He said he can't modify anything server-side, so this probably belongs to superuser I think, as it describes a problem having no solution client-side.
– Vlastimil
2 hours ago
I'm voting to close this question as off-topic because the OP is asking something he can't influence himself. He said he can't modify anything server-side, so this probably belongs to superuser I think, as it describes a problem having no solution client-side.
– Vlastimil
2 hours ago
1
1
I am specifically asking for a client-side solution. I can't influence the server, but I have full control over the client O/S (Ubuntu) and I want this specific O/S installation to trust the certificate just like other O/S (Windows) do. It's not about fixing the HTTPS site for others.
– Udo G
1 hour ago
I am specifically asking for a client-side solution. I can't influence the server, but I have full control over the client O/S (Ubuntu) and I want this specific O/S installation to trust the certificate just like other O/S (Windows) do. It's not about fixing the HTTPS site for others.
– Udo G
1 hour ago
That is exactly why I believe it is off-topic here. I'm off to go, see you.
– Vlastimil
1 hour ago
That is exactly why I believe it is off-topic here. I'm off to go, see you.
– Vlastimil
1 hour ago
The question is about using/administering a *nix system and applications packaged therein
– Udo G
1 hour ago
The question is about using/administering a *nix system and applications packaged therein
– Udo G
1 hour ago
|
show 4 more comments
1 Answer
1
active
oldest
votes
The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.
Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.
If your admin refuses/can't do this for some reason, your alternative option is to try and get curl to work with the malformed handshake.
According to a message on the Curl mailing list:
Can someone confirm if cURL supports (or not) intermediate certificate?
Yes it does.
All ca certificates have a certificate chain going up to the root. The ca
bundle you use with curl needs to consist of the certs for the entire chain.
/ daniel.haxx.se
You should be able to add the Root CA and all intermediates certificates to a bundle and point curl to it using the --cacert <file> option.
As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it as issuing.cer. Join the two together in a single file (e.g. chain.cer) and use that as the argument to -cacert.
As kindly pointed out by @A.B. the missing certificate can also be found here.
It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using--cacert cacert.pembut CURL still does not accept the certificate.
– Udo G
2 hours ago
1
It is your server. Runecho q | openssl s_client -showcerts -connect betriebsheft.vog.it:443and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should.
– garethTheRed
1 hour ago
@garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
– Udo G
1 hour ago
Windows uses the AuthorityInformationAccess extension in certificates to download missing CA certificate. Firefox (all platforms) and command-line tools such ascurldon't use it. Many argue it covers up bad server admin. But it does help Windows magically fix (hide?) problems such as this.
– garethTheRed
1 hour ago
1
The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
– A.B
35 mins ago
|
show 5 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f490608%2fhow-to-make-gnu-linux-trust-a-certificate-thats-trusted-by-windows-out-of-the-b%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.
Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.
If your admin refuses/can't do this for some reason, your alternative option is to try and get curl to work with the malformed handshake.
According to a message on the Curl mailing list:
Can someone confirm if cURL supports (or not) intermediate certificate?
Yes it does.
All ca certificates have a certificate chain going up to the root. The ca
bundle you use with curl needs to consist of the certs for the entire chain.
/ daniel.haxx.se
You should be able to add the Root CA and all intermediates certificates to a bundle and point curl to it using the --cacert <file> option.
As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it as issuing.cer. Join the two together in a single file (e.g. chain.cer) and use that as the argument to -cacert.
As kindly pointed out by @A.B. the missing certificate can also be found here.
It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using--cacert cacert.pembut CURL still does not accept the certificate.
– Udo G
2 hours ago
1
It is your server. Runecho q | openssl s_client -showcerts -connect betriebsheft.vog.it:443and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should.
– garethTheRed
1 hour ago
@garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
– Udo G
1 hour ago
Windows uses the AuthorityInformationAccess extension in certificates to download missing CA certificate. Firefox (all platforms) and command-line tools such ascurldon't use it. Many argue it covers up bad server admin. But it does help Windows magically fix (hide?) problems such as this.
– garethTheRed
1 hour ago
1
The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
– A.B
35 mins ago
|
show 5 more comments
The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.
Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.
If your admin refuses/can't do this for some reason, your alternative option is to try and get curl to work with the malformed handshake.
According to a message on the Curl mailing list:
Can someone confirm if cURL supports (or not) intermediate certificate?
Yes it does.
All ca certificates have a certificate chain going up to the root. The ca
bundle you use with curl needs to consist of the certs for the entire chain.
/ daniel.haxx.se
You should be able to add the Root CA and all intermediates certificates to a bundle and point curl to it using the --cacert <file> option.
As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it as issuing.cer. Join the two together in a single file (e.g. chain.cer) and use that as the argument to -cacert.
As kindly pointed out by @A.B. the missing certificate can also be found here.
It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using--cacert cacert.pembut CURL still does not accept the certificate.
– Udo G
2 hours ago
1
It is your server. Runecho q | openssl s_client -showcerts -connect betriebsheft.vog.it:443and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should.
– garethTheRed
1 hour ago
@garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
– Udo G
1 hour ago
Windows uses the AuthorityInformationAccess extension in certificates to download missing CA certificate. Firefox (all platforms) and command-line tools such ascurldon't use it. Many argue it covers up bad server admin. But it does help Windows magically fix (hide?) problems such as this.
– garethTheRed
1 hour ago
1
The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
– A.B
35 mins ago
|
show 5 more comments
The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.
Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.
If your admin refuses/can't do this for some reason, your alternative option is to try and get curl to work with the malformed handshake.
According to a message on the Curl mailing list:
Can someone confirm if cURL supports (or not) intermediate certificate?
Yes it does.
All ca certificates have a certificate chain going up to the root. The ca
bundle you use with curl needs to consist of the certs for the entire chain.
/ daniel.haxx.se
You should be able to add the Root CA and all intermediates certificates to a bundle and point curl to it using the --cacert <file> option.
As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it as issuing.cer. Join the two together in a single file (e.g. chain.cer) and use that as the argument to -cacert.
As kindly pointed out by @A.B. the missing certificate can also be found here.
The real fix for this is to ensure that your server presents all certificates in the chain and not just the end-entity (server) certificate.
Point your server administrator to RFC 5246 Section 7.4.2 which clearly states that This message conveys the server's certificate chain to the client.
If your admin refuses/can't do this for some reason, your alternative option is to try and get curl to work with the malformed handshake.
According to a message on the Curl mailing list:
Can someone confirm if cURL supports (or not) intermediate certificate?
Yes it does.
All ca certificates have a certificate chain going up to the root. The ca
bundle you use with curl needs to consist of the certs for the entire chain.
/ daniel.haxx.se
You should be able to add the Root CA and all intermediates certificates to a bundle and point curl to it using the --cacert <file> option.
As your browsers work, you can access the correct CA certificates from there. On the certificates tab (different for each browser, but I'm sure you'll figure that one out), view the certificate chain. Double-click the Root CA first Globalsign Root CA - G1 and on the Details tab, click on Copy to file.... Save it as root.cer. Do the same with the AlphaSSL CA - SHA256 - G2 and save it as issuing.cer. Join the two together in a single file (e.g. chain.cer) and use that as the argument to -cacert.
As kindly pointed out by @A.B. the missing certificate can also be found here.
edited 15 mins ago
answered 2 hours ago
garethTheRed
24k36079
24k36079
It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using--cacert cacert.pembut CURL still does not accept the certificate.
– Udo G
2 hours ago
1
It is your server. Runecho q | openssl s_client -showcerts -connect betriebsheft.vog.it:443and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should.
– garethTheRed
1 hour ago
@garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
– Udo G
1 hour ago
Windows uses the AuthorityInformationAccess extension in certificates to download missing CA certificate. Firefox (all platforms) and command-line tools such ascurldon't use it. Many argue it covers up bad server admin. But it does help Windows magically fix (hide?) problems such as this.
– garethTheRed
1 hour ago
1
The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
– A.B
35 mins ago
|
show 5 more comments
It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using--cacert cacert.pembut CURL still does not accept the certificate.
– Udo G
2 hours ago
1
It is your server. Runecho q | openssl s_client -showcerts -connect betriebsheft.vog.it:443and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should.
– garethTheRed
1 hour ago
@garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
– Udo G
1 hour ago
Windows uses the AuthorityInformationAccess extension in certificates to download missing CA certificate. Firefox (all platforms) and command-line tools such ascurldon't use it. Many argue it covers up bad server admin. But it does help Windows magically fix (hide?) problems such as this.
– garethTheRed
1 hour ago
1
The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
– A.B
35 mins ago
It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using
--cacert cacert.pem but CURL still does not accept the certificate.– Udo G
2 hours ago
It's not my server, so can't modify anything server-side. I tried to use the CA bundle from curl.haxx.se/docs/caextract.html (since Firefox trusts the certificate) and pass it using
--cacert cacert.pem but CURL still does not accept the certificate.– Udo G
2 hours ago
1
1
It is your server. Run
echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443 and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should.– garethTheRed
1 hour ago
It is your server. Run
echo q | openssl s_client -showcerts -connect betriebsheft.vog.it:443 and you will see only one certificate being presented by your server. There should be two - the end-entity cert (which is presented) and the issuing CA - the Alpha SSL - SHA256 - G2 certificate. The latter isn't being sent by the server, but should.– garethTheRed
1 hour ago
@garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
– Udo G
1 hour ago
@garethTheRed : I understand that the server does not present all certificates, but the server is not under my control (that's what I meant with "not my server"). I'm just trying to access an API on an foreign server. Under Windows, none of my browsers complain about the certificate, only Linux/Debian/Ubuntu does.
– Udo G
1 hour ago
Windows uses the AuthorityInformationAccess extension in certificates to download missing CA certificate. Firefox (all platforms) and command-line tools such as
curl don't use it. Many argue it covers up bad server admin. But it does help Windows magically fix (hide?) problems such as this.– garethTheRed
1 hour ago
Windows uses the AuthorityInformationAccess extension in certificates to download missing CA certificate. Firefox (all platforms) and command-line tools such as
curl don't use it. Many argue it covers up bad server admin. But it does help Windows magically fix (hide?) problems such as this.– garethTheRed
1 hour ago
1
1
The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
– A.B
35 mins ago
The missing intermediate cert (as mentioned by @garethTheRed) can be found there: support.globalsign.com/customer/portal/articles/… . OP initially only tried to add the root cert which was probably already in place, thus achieving nothing.
– A.B
35 mins ago
|
show 5 more comments
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f490608%2fhow-to-make-gnu-linux-trust-a-certificate-thats-trusted-by-windows-out-of-the-b%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
why the downvote?
– Udo G
2 hours ago
1
I'm voting to close this question as off-topic because the OP is asking something he can't influence himself. He said he can't modify anything server-side, so this probably belongs to superuser I think, as it describes a problem having no solution client-side.
– Vlastimil
2 hours ago
1
I am specifically asking for a client-side solution. I can't influence the server, but I have full control over the client O/S (Ubuntu) and I want this specific O/S installation to trust the certificate just like other O/S (Windows) do. It's not about fixing the HTTPS site for others.
– Udo G
1 hour ago
That is exactly why I believe it is off-topic here. I'm off to go, see you.
– Vlastimil
1 hour ago
The question is about using/administering a *nix system and applications packaged therein
– Udo G
1 hour ago