Hostname and Approver Email selections when ordering "only" SSL Certificates might need adjustments?

[bigtime.php]

I think it's great RSP has recently enabled the ability to order just SSL Certificates by themselves.

When ordering SSL Certificates in the RSP CP I have noticed a few things and I also have a few questions:

1.) When ordering an SSL Certificate I have learned that typically you "always" want to enter the "www" for your hostname (www.example.com) so that the SSL Certificate will be then configured to secure "both" the "www" and "non-www" version of your sites domain. The problem is that when you input www.example.com for the hostname your approver email selections now become: admin@www.example.com ; administrator@www.example.com etc.............. - Usually an accurate email address for sending the approver email will not have the "www" in the email address. So sending an approver email to admin@www.example.com will more than likely fail and get rejected by the customer's mail server.

-Can this be adjusted to “NOT” have the “www” in the available approver email selections when you include the “www” as part of the hostname?

-What if the approver email address “options” provided to me is not an active email address for my customer when ordering “only” an SSL Certificate?

-Is there any way we can provide a “custom” approver email address when ordering “only” an SSL certificate for a customer?

-How does RSP handle rejected approver emails being sent out?

2.) I have noticed that the system does not always pull in the actual “whois email address” for an entered hostname: especially if you include the “www” as part of the hostname. Even though you can set up your site to only 301 redirect to only one version of your sites domain through a redirect rule within a .htaccess file and configuring Wordpress as such etc…….- but that’s up to your customer to decide what “version” of their site they want to display: “www” vs “non-www” etc….... -Either way it’s best to order the SSL Certificate for your customer where it is already configured to secure “both” versions, “www” and “non-www” of your sites URL/hotname/domain etc……. -So therefore, unless I’m missing something, it’s always best to include the “www” in your hostname when ordering an SSL Certificate for your customer within RSP’s CP.

-If the system is having difficulty pulling in the actual “whois email address” for a hostname is there anyway we can use the customer’s email address they provided in the “account owner’s section” for the SSL Certificate approver email address? Or again, just provide the ability to enter a custom approver email address?

3.) Sense I have not yet ordered “only” an “SSL Certificate” by itself for a customer (but I do plan on potentially doing so in the future):

- What does the customer get? Obviously the customer will get their SSL Certificate emailed to them, but I mean CP wise, do they just get access to their own Hepsia CP where it just has the SSL Certificate within it so they can manage the billing and renewing it etc……...Just curious so I’m knowledgeable about it?

Helping me answer the above 3 issues/questions would be greatly appreciated. Thanks.

[c.ivanov]

Hello,

1) We have noticed the issue and it is already fixed from our developers. Now when you enter the hostname with www, the approval emails are generated correctly (without www).

The approval email can be send only from us, since we are managing the billing of your clients and you are not able to send a custom email yourself.
We do not trace such rejected approval emails because they are automatically send by the system and we do not receive the bounce messages.
If the approval email is not valid and the client has not approved/received the SSL certificate he/she will contact us via ticket and we will help him/her to verify/receive and install the SSL certificate.

2) The SSL certificate is always valid for both the domain name ( domain.com ) and the www subdomain ( www.domain.com ) even if you have not included the www subdomain in the hostname when ordering the SSL certificate.

The approval email address cannot be a custom email address. This is a restriction of the SSL vendor.

3) When someone orders only a SSL Certificate, he/she will get a billing account, the same as when ordering just a domain name registration, from where he/she can renew the SSL certificate.
From the billing account they can order a domain name registration as well or even upgrade it to a hosting account.

Best Regards,
Cvetan Ivanov

[bigtime.php]

1.) OK, I now see your developers have fixed it. Thank you. Also I appreciate your response in how you will handle bounced/rejected approver emails etc…….because I can see this happening sometimes due to fact the SSL vendor restricts being able to input a custom approver email address. I understand why the vendor has to do this - because it’s a domain validated SSL. It is what it is. At least I now know a little more how you will handle such bounced emails etc……..which in turn helps me adjust my site accordingly.

2.) Unless something has changed since you switched vendors from Rapid SSL to Comodo Positive SSL (and I’m happy you switched vendors, I like Comodo) - I don’t believe what you said is accurate. I actually ordered an SSL in the past “without” including the “www” in the hostname and the SSL turned out to be “only” valid for (domain.com) - the sub-domain (www.domain.com) was not valid. I then had to “re-order” a new SSL certificate and make sure I included the “www” in the hostname so it would “now” be valid for “both” (domain.com) and the sub-domain (www.domain.com).

-So has something changed in your automated ordering system or since you switched SSL vendors where “not” having to include the “www” in the hostname while ordering SSL’s will STILL produce an SSL that is valid for “both” (domain.com) and (www.domain.com)? Please confirm for accuracy, because in the past I have experienced otherwise.

-Important: Also I have noticed that the “order form” when directly visiting a store master theme site does a better job at pulling in the actual whois email address for a domain (hostname) versus the “order form” from within the RSP CP. In other words: the order form at https://checkout.duoservers.com is doing a better job at pulling in the actual “whois email address” for a hostname than the order form at https://cp.resellerspanel.com/orders/new/ when ordering an SSL Certificate. I don’t know why? Try inputting: (example: www.xtremefitness.com) for the hostname at “both” order forms. The order from at https://checkout.duoservers.com will pull in the actual whois email address of: passage111 (at) aol.com whereas the order form within the RSP CP at https://cp.resellerspanel.com/orders/new/ will “not” pull in any whois email address for: (example: www.xtremefitness.com) hostname. I don’t know why? Can you investigate and/or fix this for the RSP CP order form when ordering SSL’s?

3.) That is good. Perfect. Thank you for confirming this for me.

So for numbers 1 and 3 above I am now good.

Can you please investigate/confirm my questions regarding number 2 above. Especially the order form discrepancies regarding pulling in whois email addresses for hostname domains?

[c.ivanov]

Hello,

Yes, my statement is valid for the new Comodo Positive SSL certificates. It doesn't matter if you order the SSL for www.domain.com or for just domain.com the SSL will be valid for both.

We have also fixed the issue with the fetching of the whois email address.

Best Regards,
Cvetan Ivanov

[bigtime.php]

Great!! I see you have indeed fixed the fetching of the whois email address for the RSP CP order form. Thank you very much.

I'm certainly happy your statement is in fact valid for the new Comodo Positive SSL certificates. It's so much easier to not have to worry about inputting "www" vs "non-www" for the hostname - it's nice knowing they'll "both" be valid with the Comodo SSL no matter how you type it in. That's great news!!! Thank you.

[Tom Alexander]

I am not sure about that.

If you order an SSL for www.domain.com it will be valid for both - www.domain.com and domain.com, but if you order it for domain.com - it will be valid for domain.com only. So it is always better to go with www.domain.com

At least that's with the Comodo PositiveSSL Certificate (it could depend on the vendor as well).

[c.ivanov]

Hello Tom,

Long time no see.

The following is a Comodo PositiveSSL certificate recently ordered for a client:

Common name: rentcbf.com SANs: rentcbf.com, www.rentcbf.com Valid from January 4, 2016 to January 4, 2017 Serial Number: 07177a3d210e8e450d7ad144587d511c Signature Algorithm: sha256WithRSAEncryption Issuer: COMODO RSA Domain Validation Secure Server CA

You can verify that www.rentcbf.com is listed in the SANs (Subject Alternative Name) list. All hosts listed in there are also protected from this SSL certificate.

The SSL certificate is currently installed so you can verify that on your end.

Best Regards,
Cvetan Ivanov

[Tom Alexander]

True that, I just checked few of mines. Wasn't the case few months ago.

Nice to see you Cvetan

[bigtime.php]

That was a smart move switching to Comodo PositiveSSL Certificates. They are pretty popular certificates right now and they make a lot more sense validating both www and non-www regardless of how you happen to type it into the hostname field.

But just make sure you have already chosen what version, www vs non-www, you want to use for your site before typing that version into the hostname field. Even though both versions will certainly be validated, you will still want your "common name" (see above) to be the version, www vs non-www, you have chosen to present to the world (and google).

In other words, you don't want your site 301 redirecting to the https://example.com version of your site but the certificate was actually issued to the https://www.example.com version of your site - regardless of the fact that both versions are validated.

It's still much better that Comodo possitiveSSL will validate both (always) - just make sure the common name matches the version of your site you chose to present to the world. It just helps Google also understand this is the version of your site you want them to index and it just looks better overall.

The old certificate through me off when ordering a new Comodo PositiveSSL certificate because I thought it still worked like the old Rapid SSL certificate and this is something I'm needing to fix for myself. Don't know if it's possible to switch the "common name" on an "existing Comodo PositiveSSL certificate" from the www.example.com version to the example.com version. Of course still have both versions validated - but just flip flop the "common name?"