RSA CommonName does NOT match server name

labrocca

labrocca

Verified User
Joined
Mar 12, 2006
Messages
138
[Fri Feb 08 03:40:36 2008] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Feb 08 03:40:36 2008] [warn] RSA server certificate CommonName (CN) `localhost' does NOT match server name!?
[Fri Feb 08 03:40:36 2008] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Feb 08 03:40:36 2008] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Feb 08 03:40:36 2008] [warn] RSA server certificate CommonName (CN) `localhost' does NOT match server name!?
[Fri Feb 08 03:40:36 2008] [warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Fri Feb 08 03:40:36 2008] [warn] RSA server certificate CommonName (CN) `localhost' does NOT match server name!?
Click to expand...

Well...how do I resolve this? I am using apache 2.2 on my server. I can rebuild the cert no problem but I can't seem to figure out the "ServerName".

I have SSL shut off on ALL sites right now as far as I can tell.

I have added ServerName localhost to the httpd.conf and the extra/httpd-ssl.conf. The cert does display the CN=localhost as well. So why the errors?

Help is appreciated.
 
I'm having this same issue and can't figure it out also

I've got TLS enable for proftpd, also, and when connecting with TLS, the certificate says it's issued by localhost, with no other information

I have certificates working fine for :2222 on any user https login (I purchased certificates)

httpd and proftpd just happen to have the localhost funkyness
 
Well I never did figure it out but such is life. Maybe one day we will have an answer.
 
after digging more it seems that as if anything that uses the "shared" server certificates I purchased are not getting resolved because for some reason it "localhost" does not seem to be getting the certs. It doesn't seem to be translating localhost, and grabbing the certs as specified in directadmin.conf file

the https://www.appeltech.org:2222 (my server hostname is osiris.appeltech.org) does successfully grab the installed certs, and any other account created grabs those successfully on :2222, but not on anything else, (ie proftpd, or if using "shared" certificates of the server).
 
I also had the same error messages after a new directadmin install.

The warning message concerning the certificate being a CA I ignored as I am using a self signed certificate which is by definition a CA certificate. Until I purchase a SSL certificate I have know choice but to be my own CA.

Concerning the hostname not matching message I was able to resolve that issue by editing the "ServerName" directive in both the /etc/httpd/conf/extra/httpd-ssl.conf & /etc/httpd/conf/extra/httpd-vhosts.conf to be exactly the same as the CommonName (CN) in my Apache certificate /etc/httpd/conf/ssl.crt/server.crt

you can check what the CommonName is (CN=<domain name>) by using the openssl command:

openssl x509 -in server.crt -noout -subject

DirectAdmin has its own certificate in the /usr/local/directadmin/conf/cacert.pem which is used when connecting to port 2222. You can edit the config file directadmin.conf to point to the Apache certificates if you just was to use one certificate for the server.

Cheers,

Gary
 
when I do that command, I get

Error opening Certificate server.crt
12189:error:02001002:system library:fopen:No such file or directory:bss_file.c:352:fopen('server.crt','r')
12189:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:354:
unable to load certificate
Click to expand...
 
What's the filename of your cert? It's not server.crt.

And are you in the right directory?

Jeff
 
I get the same problem

RSA server certificate CommonName (CN) `localhost' does NOT match server name!?

In my /etc/httpd/conf/extra/httpd-ssl.conf file there is absolutely no "ServerName" directive and /etc/httpd/conf/extra/httpd-vhosts.conf.

I actually just want to use one domain for this server. But im getting tired of this, becoz i always get this and can not connect to apache
 
Last edited:
"Buy and install a certificate for your servername."

Should my hostingcompany not do this?

I have a dedicated server, what and where should I buy?

im lost

Danny
 
dannyman1234 said:
Should my hostingcompany not do this?
Click to expand...
Not necessarily. We don't include commercial certificates with dedicated servers; I'd doubt that many (if indeed any) do.

I have a dedicated server, what and where should I buy?

im lost
Click to expand...
If I were to recommend a Certificate vendor I'd recommend me. If you're lost I'd still recommend me, as we offer a Certificate with installation at a reasonably low price. Please contact me by email if you're interested in getting a Certificate from us.

Note that a Certificate will only work for your server name on port 2222, so you'd have to tell your clients to log in through your servername instead of their domain name.

Jeff
 
I have no idea what you are talking about.

I have bought a official DA licence for 18$ / month. I have only 1 website running on a dedicated server.

So for what do I need a certificate? I already have a licence, so should DA not give me this?

Its UNBELIEVABLY confusing

Danny
 
You don't need a certificate; it seems as if you wanted one. If you don't want one simply ignore the warning; it's not an error.

DirectAdmin does give you instructions for installing a Secure Certificate which will match your hostname, but you'll still get an error until/unless you accept the self-signed certificate.

If you're looking at a Certificate for DirectAdmin itself:

See the DirectAdmin Installation Guide and this knowledgebase article.

If you need someone else to do the installation for you, you can hire someone or learn how. Our price, for a commercial certificate, installed, is generally (but not always) less than the cost of having someone work on your server.

If you're looking for a Certificate for your site, then you can install one directly from the control panel; see this Site-Helper article. You can either create a CSR and use it to buy a Certificate, or you can create a self-signed Certificate.

The CommonName is your domain name; for example, www.example.com.

Jeff
 
I'll try to explain some basics about certs.

Any SSL/TLS-tunneled service, as it is HTTPS, needs to communicate a server certificate to the client. It's a public piece of data created starting by another piece of data (a private key) and in the special case of HTTPS it should be digitally signed by another piece of data (a CA private key) using a certificate request.

Any website must have its own certificate, because every certificate has a property named CN (or CommonName) which contains the website hostname (wildcards are accepted, so you could for example have the cert with CN=*.domain.ext and use it for both www.domain.ext and forum.domain.ext).

There are three common types of certificates:

- "snakeoil" certificate
It's the cert Apache creates during the install and uses by default, as many other programs do, and it's absolutely invalid. Not only because it's CN is "localhost", but because it's not signed by any official CA so it can not be verified.

- "self-signed" certificate
You can create a private key, a certificate request, a "bogus" CA private key (optionnally, or just use the same private key), and produce with those a self-signed certificate. The advantage of this is that you can put something in the CN property, but this cert is invalid just as the snakeoil one. Any modern browser will ask the user if he's ok about connecting to the website.

- signed/normal/correct certificate
You can create a private key, create a certificate request and send this one to any official CA service. YOU GENERALLY HAVE TO PAY THOSE, and since certs expire you have to pay them periodically. They will give you the signed cert.

The verification is done by the browser. Any modern operating system and browser has a database or directory with all the public certs derived from each CA private key, and using those they can verify the signature.

Now, there are companies that offer certs, but these usually are:
- included in the price when buying a domain or hosting for a domain
- of lower security and quality (you won't have the "green address bar" in Firefox when visiting the site, you can't have wildcards, etc)
- sometimes the CA is not even official, which means that it is recognized only by some or no browsers

So no, DA should not give you any cert. They are not an official CA, they just write and support the control panel for the platform in which you built your hosting business.
 
Thanks for taking the time to do a writeup I'd never have time to do.

I'd take issue with you on two of your points:
- included in the price when buying a domain or hosting for a domain
Click to expand...
I suppose there may be some companies which will give away a Certificate when you buy a domain or hosting, but I've never seen one; I've only seen extra-cost options.
- of lower security and quality (you won't have the "green address bar" in Firefox when visiting the site, you can't have wildcards, etc)
Click to expand...
Perhaps you didn't go far enough <smile>... EV (so called green bar) Certificate standards do not permit the use of wildcard certificates.

I'd probably also take issue with your use of lower security and quality of the less expensive Certificates. Security... okay, because to buy some of them you only need what we call domain verification; we'll sell our base level domain-verified Certificate (the blue bar Certificates) to anyone who has control of email for a domain. But frankly that's all that most people want. Most people don't want to verify their business to buy a Certificate. Or pay the larger sum required to get the CA to do the extra verification work.

But the Certificates are the same in terms of how they're constructed; the Certificates themselves are of no lower security or quality.

We've always offered the higher levels of Certificates. We're anxious to sell one, but to this day, we never have.

I just did a bit of checking... PayPal (https://www.paypal.com/) uses a green bar EV certificate, while Amazon (https://www.amazon.com/) uses a blue bar domain verified certificate (no ownership information; only email control, was required to get the Certificate).

Here's a good question: do any of us here use the EV certificate on our own sites? Sell them (not just offer them, but actually makes sales of them) to our clients?

Jeff
 
Of course higher level certificates do not allow wildcards, but low cost, low level certificates do not too, and that's what I was aiming at. ;)

Since anyone who needs an higher level certificate won't probably use shared hosting or even a managed hosted server, it's quite understandable that you never sold one. However, in my world, that's all I see... at least in the finance field, for e-banking and online stocks trading.
As always, the amount of money loss (paired with the risk possibility and frequency) involved in a security breach influences in a heavy manner the money a company will provide to implement security measures and raise the overall security level. That's why you have a strong certificate for Paypal, and a slightly less strong one for Amazon.
If a guy gets his account hijacked on Amazon, he may lose his credit card month limit at worst. If the same guy has his stocks trading account hijacked, he may lose much much more (and the bank too). And, the second one is even more frequent than the first.

We are OT, but it's good info for everyone ;)
 
My last post (offtopic) on this: most people think the Warranty provided by the Certificate provider provides indemnity to the user of the site protected by the Certificate. It doesn't.

It provides indemnity to anyone mislead if the provider accidentally issues a Certificate to the wrong site.

Which is why I think the extra security offered by the EV Certificates and other more expensive Certificates which verify site ownership is more apparent than real.

My recollection (perhaps no longer correct) is that the only known Certificate issue which could have triggered the warranty was when Verisign accidentally issued a Certificate with Microsoft in the name. That wasn't one of those inexpensive domain-validated Certificate, but a full company verified Certificate. Possibly only hearsay but I remember a lot of chatter about it at one time. If my recollections are correct, then they revoked it before anyone lost money so they never had to pay out.

Note carefully that since a Certificate warranty is only good if someone goes to a different website, it doesn't protect Microsoft from any financial liability; the site visitor would never be on a Microsoft site, but rather on a phishing site. I agree that there could be some loss of goodwill, but I don't see any financial liability.

However, I agree that the presence of the green bar is important to many entities.

Jeff
 
tillo said:
I'll try to explain some basics about certs.

Any SSL/TLS-tunneled service, as it is HTTPS, needs to communicate a server certificate to the client. It's a public piece of data created starting by another piece of data (a private key) and in the special case of HTTPS it should be digitally signed by another piece of data (a CA private key) using a certificate request.

Any website must have its own certificate, because every certificate has a property named CN (or CommonName) which contains the website hostname (wildcards are accepted, so you could for example have the cert with CN=*.domain.ext and use it for both www.domain.ext and forum.domain.ext).

There are three common types of certificates:

- "snakeoil" certificate
It's the cert Apache creates during the install and uses by default, as many other programs do, and it's absolutely invalid. Not only because it's CN is "localhost", but because it's not signed by any official CA so it can not be verified.

- "self-signed" certificate
You can create a private key, a certificate request, a "bogus" CA private key (optionnally, or just use the same private key), and produce with those a self-signed certificate. The advantage of this is that you can put something in the CN property, but this cert is invalid just as the snakeoil one. Any modern browser will ask the user if he's ok about connecting to the website.

- signed/normal/correct certificate
You can create a private key, create a certificate request and send this one to any official CA service. YOU GENERALLY HAVE TO PAY THOSE, and since certs expire you have to pay them periodically. They will give you the signed cert.

The verification is done by the browser. Any modern operating system and browser has a database or directory with all the public certs derived from each CA private key, and using those they can verify the signature.

Now, there are companies that offer certs, but these usually are:
- included in the price when buying a domain or hosting for a domain
- of lower security and quality (you won't have the "green address bar" in Firefox when visiting the site, you can't have wildcards, etc)
- sometimes the CA is not even official, which means that it is recognized only by some or no browsers

So no, DA should not give you any cert. They are not an official CA, they just write and support the control panel for the platform in which you built your hosting business.
Click to expand...

Thank you for this explanation of certificates. I am having a similar issue after doing a new directadmin install. This is all pretty confusing to me, as I don't have a full grasp of certificates, but from what I gather here, it doesn't appear to be something I should be to concerned about.
 
Stumbled on this thread after noticing the same error. In my case, the problem was in the file /etc/httpd/conf/ips.conf. In the VirtualHost settings, ServerName was set to shared.name, which didn't match the actual server name.
 
You must log in or register to reply here.
Back
Top