I do not find the letsencrypt certificate in the trusted list published by Sonos (http://musicpartners.sonos.com/node/339 - CERTIFICATE AUTHORITIES TRUSTED BY SONOS PLAYERS).
Do you if Sonos supports the https://letsencrypt.org certificates even if they are not listed (yet)?
Thanks.
Let's Encrypt is cross-signed by DST Root CA X3, who we trust (https://letsencrypt.org/certificates/), so it's OK to use it. We do have some partners that use Let's Encrypt.
Related
I want to implement Signed Exchange within my website. I know that, in production, a certificate with the CanSignHttpExchanges extension is needed for the signed exchange. My website is hosted on AWS and I have bought the SSL certificate of my domain from SSL Store. Now I want to buy certificate from Google CA so that I can get support of CanSignHttpExchanges extension.
Now, my questions are :
if I buy a certificate from Gooogle CA, then does the support of "CanSignHttpExchanges" extension comes by default? If not, how can I get the support?
How can I add the certificate in my website?
Is there a way to auto update the certificate periodically?
Google does not sell SSL certificates. AFAIK only Digicert sells (provides) certificates with CanSignHttpExchanges.
Consult the Digicert documentation as the purchase, Certificate Signing Request and installation requires knowing the web server type and DNS provider to determine the steps. You must use ECC TLS certificates.
Get your Signed HTTP Exchanges certificate
You must replace the certificate every 90 days or sooner. The payment can be auto-rewewing. Digicert supports the ACME protocol, which requires creating an ACME Directory URL for Signed HTTP Exchanges certificate. Provided that your account has paid for the certificate, an ACME client can download and install the new certificate.
ACME Directory URLs for Signed HTTP Exchange certificates
Only DV and EV certificates include the CanSignHttpExchanges feature. This requires validating your domain and your company identity. OV is easier, and EV is verification is fairly strict. You will need your identity, phone and address details, and company information documents to be in good order and verifiable.
i builded an app running in console with Python. Then i made this app convert to exe. i wanna publish this app on the web. So i signed this app. But i see this problem:
This CA Root certificate is not trusted. Upload this certificate to the Trusted Root Certification Authorities store to be trusted.
From this warning i understand that i must my upload certificate to the Trusted Root Certification Authorities store. But i do not know it way.
My app certificate' s is:
https://www.digicert.com/support/tools/certificate-utility-for-windows
Who issued certificate:
http://127.0.0.1:5000/
Whom was issued certificate:
http://127.0.0.1:5000/
Signature algorithm:
sha256RSA
You're using self-signed certificate i.e. certificate is not issued from valid trusted Certificate Authority. If you want to publish the app for public, then you've to sign it by obtaining the certificate from valid trusted certificate authority (CA). In case, you want to manually share the app with the recipients, and they're aware of the possible risk factor then you can share the issuer certificates with them, and they've installed those into the windows trust store.
Just search for certmgr on windows and add the issuer certificates into Trusted Root Certification.
I have a web page with apache, and it is hosted only in localhost, but all devices that are connected to my network can be entered using my ipv4 (192.168.1.x), I have installed a certificate using openssl, but the certificate is only valid For my pc where I am hosting the site, if I try to enter with another device it tells me that it is not valid.
That's expected since the Certificate Authority (who emitted your certificate) is not trusted by the browsers. You'd need to install your CA certificate in your clients in order to make them trust the certificates emitted by that CA.
If you own a valid domain, you may buy a certificate for it from a trusted CA, or even emit a certificate using Let's Encrypt, which emits free SSL certificates that are trusted by all major browsers currently. Remember that this won't work neither for invalid/local domains or domains that you don't own.
I guess it can't be done, but if so, I'd like to know why.
Let's say I get an SSL certificate for example.com from one of the official certificate authorities around. Let's also say I'm running a.example.com and b.c.d.example.com and would like to have SSL certificates for those as well.
Can I use the example.com certificate to issue certificates for a.example.com and b.c.d.example.com myself? And will they be recognized by users' browsers? If not, why not?
(My guess that it can't be done is because it would break the very lucrative wildcard cert business model, wouldn't it?)
Clarification: can't I act as a "self-signed" certificate authority using the keypair for which I obtained the official cert, and simply add my official cert in the validation chain?
You cannot use Your certificate to issue other certificates, because the purposes of the
certificate are encoded in Your certificate and "Certificate Authority" is certainly not included in that list.
Web browsers check the "certificate chain" beginning from Your certificate, the certificate that was used to sign it, the signer of that certificate etc.
Your certificate must match the current use case (mostly "identify web site") and all signing certificates must include the "Certificate Authority" flag. The last certificate must be known to the browser (root cert).
As You already guess, wildcard certificates might help in Your case.
You're correct, you cannot issue certificates from a certificate. You need a Certificate Authority to issue certificates.
The whole point of a Certificate Authority is that they are a trusted 3rd party. CA's like Verisign are trusted by default by most browsers so that you dont have to manually accept certificates from them. They have what is termed a trusted root certificate.
If you create your own Certificate Authority and start dishing out certificates, web browsers will not know you and hance not trust you. The user will be prompted.
I just installed an SSL on Plesk, and when I go to https://www.example.com in Chrome, I get the error below:
This CA Root Certificate is not trusted. To enable trust, install this certificate in the Trusted Root Certification Authorities Store.
Sort of defeats the purpose of having an SSL. Any idea how I can make this message go away?
I bought the SSL from GoDaddy, which I would expect to be a trusted authority.
This issue occurs because the issuing authority has signed the server certificate using an intermediate certificate that is not present in the certificate base of well-known trusted certificate authorities which is distributed with a particular browser. In this case the authority (GoDaddy) provides a bundle of chained certificates that should be chained with the server certificate to address this issue of lack of trust. Unfortunately, GoDaddy does not provide any documentation on this front. You should have received two different certificates from GoDaddy, one for your server, and the bundle. Depending on your server, this is what the configuration would look like:
For Apache:
Specify each certificate in its own directive:
SSLCertificateFile /path/to/cert/www.example.com.crt
SSLCertificateChainFile /path/to/cert/bundle.crt
For Nginx, documented here:
Both certificates should be concatenated, first the server, then the bundle:
cat www.example.com.crt bundle.crt > www.example.com.chained.crt
And then use www.example.com.chained.crt in your server ssl_certificate directive:
ssl_certificate www.example.com.chained.crt
GoDaddy is recognized on Windows operating systems, because the GoDaddy root certificate is pre-installed on Windows. But GoDaddy will not be automatically recognized in many contexts and would need to be manually configured by users (which is not a trivial task). IPhone, for example, will not trust GoDaddy certificates out of the box. You may consider getting certificate from established certificate authorities such as Verisgn or Thawte, but they will be more expensive.
#John: GoDaddy is a registrar/webhost, I believe their certificates are just reseller certs. You don't need to go expensive to get compatibility as #Jaro suggests. I've deployed several RapidSSL certificates that are recognized by Chrome/iOS and Safari/iOS without user intervention and are much cheaper than the higher-insurance certificates like Symantec/VeriSign.
The only way to make that message go away, is by buying a real certificate from a trusted authority.