docker login xxx.example.com:5050 -u user -p password
Error response from daemon: Get "https://xxx.example.com:5050/v2/": x509: certificate is valid for example.com, not xxx.example.com
I'm in desperate need of help. I host my own instance of gitlab
You seem to have issued a certificate for the “apex” domain (i.e. no subdomain). A normal certificate is not valid for subdomains, only exception is the www subdomain. You have three options:
Create a certificate for subdomain.example.com.
Create a wildcard certificate for *.example.com
Create a multidomain certificate for example.com and subdomain.example.com; potentially for other subdomains as well. Some CAs allow extending a multidomain certificate with additional (sub-)domains later on, but please check in advance.
By the way, consider setting up Let’s Encrypt, and you won’t have to worry about issuing more certificates.
Related
My azure VM was generated by someone else. It has become of importance. I need to create a server certificate for Database SSL. I am using certbot with letsencrypt as shown here:
https://www.vultr.com/docs/use-ssl-encryption-with-postgresql-on-ubuntu-20-04/
I come unstuck here in this step :
sudo certbot certonly --standalone -d zz-ubuntu1
Account registered.
Requesting a certificate for zz-ubuntu1
An unexpected error occurred:
Error creating new order :: Cannot issue for "zz-ubuntu1": Domain name needs at least one dot
So, I have not put in a domain name because there does not seem to be one.
The hosts file is untouched:
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
There appears to be nothing with regards to a domain name at all:
root#zz-ubuntu1:~/tmp_certbot_key# hostname -f
ZZ-UBUNTU1
In order for the CA certificate to be generated by certbot as per the instructions I believe I need to give it an FQDN but maybe there is some dummy entry or fudge I can do...?
I have no access to the azure portal. I do have root.
Does anyone know if there are any steps I can take to generate the certificate? Preferably without doing any damage to the standalone Postgres DB that is on there.
Let's encrypt is a way to obtain publicly signed certificates. That means the certificate signing authority must have some way of verifying that the domain in the Cert signing request can be associated with the request. Generally that's done by either adding a public DNS CNAME or TXT record with the content that "proves" you own the domain, or by adding content to a web endpoint on the domain, which achieves the same evidence that you own the domain.
As an unqualified hostname, nobody owns ZZ-UBUNTU1. it's merely a string identifier. You can't get a public certificate for this name because there would be no way to verify it before signing.
Here's some things you can do:
you can sign a certificate with a non-public CA key. Keep the CA key somewhere safe, provide the CA cert to the client and the signed cert and key to the postgres server. The public won't trust the certificate, but they're not connecting to the postgres server anyway. If the CA key is secure, this is cryptographically as secure as a publicly signed certificate. This is only an appropriate solution if the certificate need not be validated by the public, who would have no reason to trust your CA certificate.
as a similar alternative, you can use a self-signed certificate. This means that the key associated with the certificate is also the key used to sign the CSR, so the CA key materials and the server key materials are the same. You can then specify the self-signed certificate as the ca-cert in your client config so the key can be verified. This also is only valid for privately used certificates, as the public would have no way to verify authenticity.
you can use a FQDN under a domain your organization controls. Your ogranization would have to allow you to update DNS or handle public http requests to the FQDN so that you can provide proof of ownership. For example, if you had example.com, you could get a publicly signed certificate for db.internal.example.com. Then you could define db.internal.example.com to be 127.0.0.1 or whatever IP in /etc/hosts. you should be aware that any FQDN with a publicly signed certificate can be discovered in the Certificate transparency logs. Further, public DNS may not reliably resolve to 127.0.0.1 or other private addresses due to security considerations, but that's more likely on home networks than in azure.
Let's Encrypt certificates are good for 90 days. The article says to restart postgres to pick up the new certificates, but this heavy-handed approach will interrupt postgresql service while the restart happens. As of postgres 10 which was some time ago, ssl certs can be reloaded without restarting the server or interrupting existing clients. So if you do end up using let's encrypt, instead of restarting your db server every 10 days and causing an outage, issue a reload instead.
Based on the documentation I've read, the "Denied" status should only happen if the domain fails to verify.
But clearly the verification passed so I'm not sure what else to do.
Attempting to follow the sub-steps under the Assign step just leads to errors related to
the cert being in the "Denied" state still.
This happens when Domain verification for the certificate is not completed in 45 days causing the certificate to be in denied state. The Certificate will not be billed.
Suggestion is to delete the certificate and request a new certificate.
Also note that: For a Standard certificate, the certificate provider gives you a certificate for the requested top-level domain and its www subdomain (for example, contoso.com and www.contoso.com). However, beginning on December 1, 2021, a restriction is introduced on the App Service and the Manual verification methods. Both of them use HTML page verification to verify domain ownership. With this method, the certificate provider is no longer allowed to include the www subdomain when issuing, rekeying, or renewing a certificate.
The Domain and Mail verification methods continue to include the www subdomain with the requested top-level domain in the certificate.
see: FAQ SSL certificates for Web Apps and App Service Certificates
Check this official document: https://learn.microsoft.com/en-us/azure/app-service/configure-ssl-certificate?tabs=apex%2Cportal#import-an-app-service-certificate
In this case, the issue was not domain verification as stated in the other answer here and in the documentation, but was a misconfigured CAA record on the DNS.
For wildcard certs you need to have an
0 issuewild godaddy.com
record on the root domain - not on a star (*) domain.
I have recently bought a web server where I issued SSL certificate and I also bought my domain. I also have VPS server where my API will be located and accessed from the web server. Now the question is this -- is there any way I can use my automatically generated SSL certicate for my VPS server as well?
I added domain like xxx.yyyy.sk and forwarded it to my VPS IP address. When I tried SSL https:// I just received an error ERR_SSL_PROTOCOL_ERROR. (this happened while I used my automatically generated certificate)
I also tried issuing certificate on my own in my VPS server using OpenSSL but it seems like I have overwritten my automatically generated certificate because now the certificate is valid but browser says it's not secure..
Is there any way to prevent this 'not secure' status? It's quite annyoing and I want to get rid of it since I am building an e-shop and it would not be appropriate for users to see 'not secure' once they fill in sensitive data.
Thank you for any sensible answers!
You can use the following command to generate a certificate with letsencrypt.
sudo certbot certonly --standalone -d xxx.yyyy.sk
How to create a Let’s Encrypt self signed certificate for a subdomain?
To be specific:
sub.domain.com (needs a certificate and points to an ip address)
domain.com (does not point to anything)
When following the following instructions, I get the following errors:
>>> sudo -H ./letsencrypt-auto certonly --standalone -d sub.domain.com --register-unsafely-without-email
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for sub.domain.com
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. sub.domain.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: sub.domain.com
Type: connection
Detail: Timeout
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
You can create Let's Encrypt Certificate for subdomain without pointing domian to any root.
Login to DNS management and create A NAME Record for subdomian. For A NAME you would need IP address
Verify sub.domian.com is accessible over internet.
run script for sub.domian.com.
https://zerossl.com/free-ssl/#crt can be also used to generate certificates and key however it would need some manual step to create .well-known and aceme-challenge folder need to be created in sub.domian.com /DocumentRoot
You need to run the commands on the server, cause the command verifies you control the domain, so if it's not on the server it can't verify correctly.
We have two A records pointing to same public IP address as:
www.example.com IN A 192.*.*.*
example.com IN A 192.*.*.*
We have certificate issued by Verisign to www.example.com. Now when the user types https://www.example.com/xyz, everything works fine as expected.
But when we use https://example.com/xyz, the browser throws an error:
"There is a problem with this website's security certificate"
And asks the user to make decision if they trust and want to go ahead.
Now what should be best practice here:
Change certificate and get wildcard certificate *.example.com
Use following setting at DNS:
www.example.com IN A 192.*.*.*
example.com IN CNAME www.example.com
Write a HTTP module in .Net pipeline to redirect user if they type example.com/xyz to www.example.com/xyz. I know this is not recommended.
We would like to do something like what chase.com is doing. If you type chase.com it takes you to https://www.chase.com/.
None of the above. You should get SSL certificate that covers two domains: www.mydomain.com and mydomain.com.
As per your proposals:
1) Having wildcard certificate for a single domain of *.mydomain.com will still give you an error when opening mydomain.com without any prefix. You may of course get a multidomain certificate for *.mydomain.com and mydomain.com
2) For the sake of SSL, it doesn't matter CNAME or A - DNS used to get the address (A record) of your webserver, afterwards browser still expects SSL certificate to match exactly what you type in the address bar.
3) That would work for http requests, but when user types https://mydomain.com, browser checks SSL certificate before it processes the redirection request, and will still show the warning.
P.S. You have this problem because CA industry is totally screwed. Their product pages all look like "super 256-bit encryption" (certificate have nothing to do with encryption strength), mobile support (be it mobile or mainframe, certficate is all the same), and "a free site-seal included" (site seal is a great name for a CA advertisement placed on your site).
All the not important things like is it's CRL or OCSP, or which domain names it covers at all - never mentioned.