How can I create a SSL certificate that has the ability to utilize a "short name" and "FQDN"?

What I am looking to do is have a internal cert created by our Enterprise CA that covers both the short name and the FQDN of a server. For example :

1. https://server1 and https://server1.domain.com 
2. https://hostrecord for server1 and https://hostrecord for server1.domain.com
So, say I have a server named "server1" with ip address of 10.0.0.1 and I create a hostrecord called" webserver1" with ip address of 10.0.0.1 and I go to a browser type https://webserver1 and/or https://webserver1.domain.com I can get to a website that was created.

Make sense?
mjm21Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ParanormasticCryptographic EngineerCommented:
What you are looking for is called a SAN (Subject Alternate Name) and can include multiple values, and can be used for hostnames, FQDNs, IPs, aliases, etc.

You can usually use the certsrv page to do this using the Attributes field, or you can do it if you install the 2003 admin pack to get certreq.exe.

certreq -submit -attrib certificatetemplate:%TemplateName%\nSAN:%SANValues% -config %CA.FQDN%\CAName -f %ReqPath%\%filename.csr% %DestPath%\%CertName%.cer >> SubmitCSR.log

For certsrv, you can combine using either & or /n, for certreq the same applies.  I like to script, so using in a script you have to /n because & is a parsing char for batch files.  Either way, you don't need spaces.


e.g. email: YourEmail@domain.com\n dns: SQLalias.domain.com
email: YourEmail@domain.com
dns: SQLalias.domain.com
dn: CN=hostname,OU=USA,DC=domain,DC=com
ipaddress: 192.168.0.1
0
ParanormasticCryptographic EngineerCommented:
Personally, for internal things I like to use the hostname for the main name, then the dns, ip, alias, etc. for the SAN values.  I just don't like doing the full DN structure, although you canusually get away with just DN: CN=hostname without all the fluff.
0
mjm21Author Commented:
Thanks member 22688981 and 22689003 I have read about the SAN and I am familiar with using certserv page, rather then the scripting.  However, I agree with the hostname as main name for the main portion of the cert, but I am still unclear what to type in the attributes page under the advanced tab in the certserv.  
0
Redefine Your Security with AI & Machine Learning

The implications of AI and machine learning in cyber security are massive and constantly growing, creating both efficiencies and new challenges across the board. Check out our on-demand webinar to learn more about how AI can help your organization!

mjm21Author Commented:
I have also read that you have to prepare the CA for the SAN by typing in this in the command line:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
0
mjm21Author Commented:
Sorry ...new to this site....Thanks user Paranormastic!
0
ParanormasticCryptographic EngineerCommented:
Funny I don't think I've been called by my user number before :)
Yes, the certutil command is needed to do SAN's.

Assuming cert has 'server1' as Subject, then SAN entry into the Attribute field would be:
SAN:dns:server1.domain.com/ndns:webserver1.domain.com/nDN:CN=webserver1/nipaddress:10.0.0.1

note no spaces. you can substitute /n for & if you wish, shouldn't really matter.  the order doesn't really matter, except that it needs to start with SAN:, for some reason some things like to work better with a : than a = and vice versa but technically shouldn't really matter, again I typically script certreq so I'm a little rusty on the quirks of certsrv page.
0
ParanormasticCryptographic EngineerCommented:
certutil, certreq, and openssl can be your best friend if you are going to be getting into CA stuff for somewhat regular usage.  here is a handy page for a few odd other extensions you may want to consider:
http://technet.microsoft.com/en-us/library/cc740063.aspx
0
mjm21Author Commented:
OK...so:
webserver1.domain.com/nDN:CN=webserver1/nipaddress:10.0.0.1 (This is the alternate name that I created in DNS)
0
mjm21Author Commented:

I guess this is what I mean....and I follow up all the way up to the attribute.....

What I am looking to do is have a cert that covers both the short name and the FQDN of a server. For example https://tombs and https://tombs.olf.com

So if I type either one of the above, I still get to the website even though the "real" server name is say Paranormastic.

I have already created a host record called tombs that point to Paranormastic.....

OH...so webserver1 is the hostname created in DNs that points to server1..... right?

Can I create multiple san's for one cert?  So, how would the atribute read if say we now added webserver2 to the picture.......

And that is all I have to ask.....thanks :)
0
ParanormasticCryptographic EngineerCommented:
You can add a whole slew of SAN's to the same cert, yes - just string them together with /n or &.  For commercial certs they may charge based on the number you add, but your own CA... I don't know what the limit is offhand but its a whole lot.  You got the general idea, but the main name does not need to be included in the attribute field as that would be in the subject field in the CSR file, the rest would go into the Subject Alternate Name.

You could tecnically add entries for more than one server, say if they were in a cluster responding to the same alias.  If you do this, then create the CSR on server1 and install the cert, then export it using Certificates MMC including private key, then copy it to server2 and install it there.  That way they can both handle the same data properly since they would be sharing the same private key.  

If they are different apps, then you probably want to issue a different cert than having one giant cert.  You could do a wildcard, but if you want to do hostnames and IP addresses, that probably isn't the best option and some apps (e.g. OWA) don't like wildcards much.


0
ParanormasticCryptographic EngineerCommented:
One thing that we do here is since we issue certs to a very large enterprise sized organization we get requests from all over the place, so we add the Outlook team name or support team email address as a another SAN with the email:IIS.AdminTeam@domain.com or email:"IIS Admin Team" format.  That way, when it comes time to renew it we can email that group (in case the originator moved on from the company we still have a contact).  This would show up in the Subject Alternate Name field as the RFC882 Name:
0
mjm21Author Commented:
I will check it out...thanks
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mjm21Author Commented:
I understand the concetp now.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SSL / HTTPS

From novice to tech pro — start learning today.