SUNET TCS: Frequently Asked Questions
This FAQ is about the existing TCS system that will be in use until 2015-07-01.
There is also an FAQ about the new system introduced during spring 2015.
Email email@example.com after making sure that this FAQ list does not contain the answer.
These are the kind of server certificates we have always had in SUNET TCS. Before 2013-01-16 they were just called "Server certificates". They contain C=SE and O=Your Organization and may also contain OU=Organizational Unit.
See below why you might not want to request this type of certificate unless you really need the O and OU name components!
The certificate variant shown as "Server Certificate" in the SUNET TCS web interface is a new variant introduced 2013-01-16. They only contain domain names (in the CN and Subject Alternative Names), but OU=Domain Control Validated is also added. There are no C, O or user-provided OU name components in this type of certificate.
See below why you might want to request this type of certificate even if you do not get O and OU included in the name!
From February 1st, 2013, "Server certificates with Organization Validation" requires a telephone callback from the Comodo CA to you to verify the organization information. Thus, this variant will take several days, not minutes, to get. In light of this, you should choose the simpler "Server certificates" (without Organization Validation) for certificates where the organization information is not strictly needed.
Maybe! This certificate variant now needs to contain state, locality, postal code and street address, just like the code signing certificates. If you have not already enabled code signing, you need to send in this information for OV to work.
Email firstname.lastname@example.org and tell us that you need to issue server certificates with organization validation. In the email, you will have to provide the following name components:
Choose the values that best match your (main) campus.
When we have processed your request, your users will be able to select server certificates with organization validation.
Comodo will use a reliable public phone directory to find the phone number for you organization. They will then call you to verify the organization information.
To facilitate this, we now ask for the forename, surname and email addres of a "callback" contact person, when an organization validated certificate is requested. The admin contact at the organization can accept or override the name and/or email when approving the certificate. The name and email address is sent to Comodo together with the certificate request.
After the normal Domain Control Validation via email is completed (see below), Comodo will start to look for the phone number to your organization in a reliable public phone directory and register it in their systems. This make take some time.
When this is completed, you will get an email from Comodo to the specified "callback" email address. There is a link in the email to a Callback Confirmation web page at Comodo and a code that you need to enter.
At the Callback Confirmation web page, use the "Request Manual Callback" button. Provide information about suitable date and times to call you. Also enter your extension number.
Comodo will then attempt to call the phone number to deliver a numeric code that you need to enter at the Callback Confirmation web page to finish the Organization Validation. When that is done, the certificate will be issued.
Warning: Do not use the "Call me now" or "Call me later on" buttons. They will use an automatic "robocaller", that is not capable of handling normal Swedish manual switchboards. It will try to dial the extension when the switchboard answers and/or try to read the numeric code to your switchboard staff. Great hilarity may ensue, but you will probably not get any certificate.
You use the same web application as for the "normal" server certificates, selecting the "e-Science Server certificate (ASCII)" or "e-Science Server certificate with Organization Validation (ASCII)" certificate variant.
You use the same web application as for the server certificates (selecting a Code Signing certificate variant), after having gone through an email registration process once (see "Updating the Registration" below).
You do not use the same web application as for the server and code signing certificates. See more information about SUNET TCS Personal.
Yes. At the moment, the minimum key size is 2048 bits. Thus, you can not get certificates based on 1024 bit keys.
Since an incident in the spring of 2011, the Comodo CA has been forced to add an extra layer of validation on top of the checks we already to in SUNET before a server certificate can be issued. The check consists of an email being sent to a specific email address in the same domain as the certificate to be issued. You prove your ownership of the domain by surfing to a URL present in the email and entering a code that is also included in the email.
When you are about to approve a server certificate for issuing, there is a drop-down menu above the comment field next to the Approve button. Select the appropriate email address there before approving to enable DCV.
If you do not use DCV via email, the certificate will be held by Comodo for additional manual validation. Comodo has stated that this might take as much as 24 hours. In the future, DCV via email will become mandatory.
At the moment (the summer of 2011), DCV cannot be used for certificates with Subject Alternative Names or for e-Science server certificates. This will change in the future.
Check that the DCV email has not been trapped by greylisting or other spam filters. You may use the Resend DCV Email button on the certificate page to request that Comodo resend the email.
If your are in a hurry and cannot use DCV via email, please contact email@example.com and we will ask Comodo to expedite your certificate.
The list of possible addresses is formed by adding five names (admin, administrator, hostmaster, postmaster, webmaster) to the domain name of the certificate, and to parent domains up to the relevant level. For example, if your certificate is for www.inst.liu.se, the possible addresses will be:
No. We have already asked Comodo about this, and they are not able to change the addresses.
Yes! On your Customer Information page, you may enter a list of preferred DCV addresses. The list is really a list of address substrings, and the first match wins.
An example: If Linköping university enters the following into that field:
firstname.lastname@example.org postmasterand then goes to approve a certificate for www.inst.liu.se, the email@example.com DCV email address will be selected in the list (as firstname.lastname@example.org is the top choice that matches email@example.com above).
If the certificate is for www.centre.liu.se, the firstname.lastname@example.org DCV email address is chosen (as no candidate DCV email address matches email@example.com, and firstname.lastname@example.org is the top candidate that matches postmaster).
TCS picks up Subject Alternative Names from an X509v3 Subject Alternative Name extension in the CSR. This means that it will work with Subject Alternative Name certificate requests from modern versions of Windows.
OpenSSL users: do not use the old SCS trick of putting multiple CN entries in the CSR. Instead, use a config file to get a CSR with the right SAN extension:
% cat santest.conf [req] default_bits = 2048 prompt = no encrypt_key = no default_md = sha1 distinguished_name = dn utf8 = yes req_extensions = v3_req [ v3_req ] subjectAltName = @alt_names [ dn ] C = SE O = Linkopings universitet CN = santest.liu.se [alt_names] DNS.1 = a.santest.liu.se DNS.2 = b.santest.liu.se DNS.3 = c.santest.liu.se % openssl req -new -config santest.conf -keyout santest.key -out santest.csr ...
Sure! Just generate a normal certificate request, upload it into the system and add additional names in the Subject Alternative Names text box (one per line).
As stated above, the old SCS trick of putting multiple CN name components in the subject name of the CSR does not work for TCS. The first CN name component is picked up and used and the extraneous ones are silently discarded.
The certificate backend used by TCS allows us to override and remove name components present in the CSR. We use this to set organization (O) to a fixed value entered in the member database and to remove the state (ST) and locality (L) name components.
We hope that this reduces the number of mistakes (where certificates have to be denied due to bad name component values).
As the organization (O) name component is fixed for a member, you cannot use the CSR to choose between "O=Linköpings universitet" and "O=Linkopings universitet", for example. Most certificate requestors want working "Swedish special characters" and will leave the setting as "Normal certificate (Unicode)". Those who need to get certificates with only ASCII name components change it to "Normal certificate (ASCII)" (and make sure that they only include ASCII in the organizational unit (OU) name component).
Yes! One such name component will be picked up from the CSR, if present. It is subject to the same domain name checks as the CN, though.
Yes, we do. Please do not abuse that to issue wildcard certificates for whole departments so that a single key is shared between multiple unrelated servers. Use wildcards for specific subdomains, handled by one server (or a tight cluster of related servers).
If you think that you need a wildcard certificate for your "top" domain (for example *.liu.se if you are Linköpings universitet), please contact email@example.com first to discuss the motivation.
Yes, only "*." at the beginning of a domain name is accepted. Earlier (before April 2012) names like "wiki*.university.se" were also accepted.
It's a bit complicated to explain, so let's divide this into two cases:
If the requested CN is a wildcard name, you cannot add Subject Alternative Names (wildcard or not).
If the requested CN is not a wildcard name, you may specify Subject Alternative Names, and they may be for wildcard names. However, wildcard Subject Alternative Names might not work with all clients.
SHA-1 signatures are getting to close to not being secure enough. Google and others are acting on this. See for example Gradually sunsetting SHA-1 that says for Chrome that HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome's user interface.
Certificates ordered through SUNET TCS before October 10, 2014 use SHA-1 signatures.
You can run a command like openssl x509 -in mycert.pem -noout -text and check if you get Signature Algorithm: sha1WithRSAEncryption (SHA-1) or something like Signature Algorithm: sha256WithRSAEncryption (SHA-2).
From October 10, 2014, if the CSR requests SHA-1, you still get SHA-1. If the CSR requests a SHA-2 variant, you get that. One exception: if you request SHA-1 but a validity beyond 2016-12-31, you will get SHA-2 (sha256WithRSAEncryption).
You can run a command like openssl req -in mycsr.pem -noout -text and check if you get Signature Algorithm: sha1WithRSAEncryption (SHA-1) or something like Signature Algorithm: sha256WithRSAEncryption (SHA-2).
SHA-2 (sha256WithRSAEncryption) is default in recent versions. You can use -sha1 to request SHA-1 or -sha256 to request SHA-2.
You tell us, and we will update the FAQ!
No! The SHA-2 certificates use different chain certificates, so that they too can use SHA-2 signatures. You get the right ones in the web portal. You cannot just copy the old SHA-1 chain certificates and use them together with the new SHA-2 certificates.
Nothing, really! The TERENA SSL CA certificate is signed by UTN-USERFirst-Hardware which is then signed by AddTrust External CA Root. One or both of these should be included as a trusted root certificate in browsers etc.
You need to tell your server to send the certificate chain to the client. You download the certificate chain at the same page where you download the certificate.
You could use openssl s_client -connect tcs.sunet.se:443 (replacing tcs.sunet.se with your address). You then have to check the lines following "Certificate chain" in the output to see that it contains more than the server certificate. The following is OK:
Certificate chain 0 s:/C=SE/O=SUNET/CN=tcs.sunet.se i:/C=NL/O=TERENA/CN=TERENA SSL CA 1 s:/C=NL/O=TERENA/CN=TERENA SSL CA i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware 2 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
Strictly speaking, certificate 3 above is not needed (as it is a root certificate that the clients need to have in their trusted root certificate stores). If certificate 2 above is missing in the chain, some clients that trust UTN-USERFirst-Hardware directly will work, while others that need the full chain up to AddTrust External CA Root will fail. If certificate 1 is missing, then you are far from having a working server.
We received reports that some clients had problems when the chain certificates were ordered as they were in the chain certificate PEM file. Reversing the order of the certificates seemed to work. After confirming with the vendor that the order we got was indeed wrong, we now (as of 2009-11-09 6 p.m) correct the order when you download the chain.
Download the whole certificate chain in PEM format and use the Apache SSLCertificateChainFile directive to point to the chain file.
First of all, you install the server certificate in the same application that you requested the certificate with. Then it is time to take care of the chain:
Use the mmc tool with the Certificates snap-in to manage certificates for the computer account of the local computer.
First, remove the "UTN-USERFirst-Hardware" certificate from the Trusted Root Certification Authorities. If you don't do this, the server will not be able to send the UTN-USERFirst-Hardware signed by AddTrust External CA Root chain certificate (part 2 below).
From the SUNET TCS certificate download page (URL beginning with https://tcs.sunet.se/collect/, download part 1 and part 2 of the certificate chain. Import each of these two files into the Intermediate Certification Authorities using the "All Tasks > Import" choice on the context menu for "Intermediate Certification Authorities > Certificates".
You do not need to import part 3 of the chain. This is the self-signed AddTrust External CA Root certificate and should already be present in the list of Trusted Root Certification Authorities.
After you are done, please check (for example using the OpenSSL method above) that the server sends the whole chain.
Yes! Please read the Do the SHA-2 certificates use the same chain certificates as the SHA-1 ones? question in the last section!
Email firstname.lastname@example.org and tell us that you want to start issuing code signing certificates. In the email, you will have to provide the following name components that are needed for code signing certificates, but not for the server signing ones:
Choose the values that best match your (main) campus.
We will confirm the request using your registered contact email address. When we have processed your request, your users will be able to select the code signing variants when applying for certificates.
The CN (Common Name) will be the same as the O (Organization) component. The value provided in the CSR will not be used.
Use the OU (Organizational Unit) component for that. The provided Contact Email address will also be present as a Subject Alternative Name (of email type).
It may take some days to get a code signing certificate, after having approved it. If you have not got the certificate after two working days, or if you receive emails from COMODO about documents etc, please contact email@example.com.
Yes, you can use the search box on the List Certificates pages to search for specific names. You may also use the All, Pending, Issued and Bad buttons to limit the matches to certain categories of certificates. Finally, the drop-down menu on the line below lets you choose the sort order.
If you sort your issued certificates in the order "Valid To (asc)", you can see the certificates in the order they will become invalid.
Yes, just use the button at the bottom of the page to download the list as a CSV file. The searching and filtering you have done will be applied to this file as well.
Yes, you get an email 90 days before the certificate expires. It is sent to the certificate requestor email address, with a copy to the customer email address.
Email firstname.lastname@example.org and tell us what domain we should add or remove from you. We will confirm the request using your registered contact email address.
To add a domain, your organisation must be listed as owner of the domain in the relevant registry. For Swedish domains, that means that when you enter the domain name in the search box at www.iis.se and then follow the OWNER (KONTAKT-ID) link at the resulting page, the ORGANISATIONSNUMMER shown will be that of your organisation. We'd also like the FÖRETAG field to contain the name of your organisation or at least something we understand is part of your organisation.
See the answer under "Code Signing Certificates" above!
Send in a new paper form like you did when first registering. List the administrative contacts you would like to have (not only new ones). Also make sure you list the domains you like to be authorized for (also the ones you might have added since you last sent in a form).
Note: new administrative contacts must create their users in the system before you write the usernames in the form. If you do not remember the URL and authorization code from the last time, just contact email@example.com to get it.