AWS Certificate Manager

== Current Alerts and Updates ==
=== Important Update ===
From September 14, 2014 to September 22, 2014, the maximum validity period for a certificate will be reduced from 3 years to 1 year. Users can choose to wait until after September 22, 2014 if they want to get a 3 year certificate.

=== Service Alerts===
See the [http://www.it.cornell.edu/services/status.cfm IT Service Alerts site] for information on current alerts and outages.

=== Scheduled Maintenance===
Whenever possible, maintenance is scheduled between 5:00 and 7:00am during the established maintenance window. Check the [http://www.it.cornell.edu/services/status.cfm IT Service Alerts site] for information on scheduled maintenance.

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

==Service Description==
===General Description===
The IT Security Office offers no-cost SSL server certificates through the InCommon Digital Certificate service. Cornell is a member of the InCommon Federation. InCommon contracts with Comodo to provide the service.

The Cornell self-service SSL request site offers:
*Single domain certificates
*Multiple domain certificates
*Unified communications certificates

InCommon also offers a code signing certificate. See [[#Escalation|Escalation]].

====What are the benefits of an SSL certificate?====

*User privacy and data integrity: data is encrypted as it moves over the network. It cannot be easily intercepted or altered.
*Strong assurance of server authenticity: the certificate is signed by Comodo's certificate authority, which is one of a limited number of certificate authorities automatically trusted by major browsers.

====When should I use an SSL certificate?====

You should use an SSL certificate in any of the following cases.

*Services that require users to authenticate.
*Services that display or ask the user to provide any of the following types of data.
**Protected by federal or state legislation (for example: medical histories, personal financial data, student visa status, social security numbers)
**Sensitive or confidential (for example: University budgets, physical security infrastructure documents, vendor contracts)
*When the ability to confirm the authenticity of the server is a requirement. For example, in a limited development environment a self-signed certificate may be acceptable. The corresponding production service, however, may require the assurance of a certificate signed by a globally-recognized certificate authority.

====What types of certificates are available?====

*Single domain certificate.
*Multi-Domain: Secures up to 100 different domain names on a single certificate. (Example: one certificate for a site with two names: www.whoiam.cornell.edu and whoiam.cornell.edu)
*Unified Communications Certificate (UCC): Secures multiple fully-qualified domains on a single certificate. Specifically designed for use with Microsoft Exchange and Microsoft Office Communications servers.
*(Coming soon) EV SSL Certificate: Extended Validation certificates provide the highest levels of encryption, security, and trust. Immediately reassure site visitors that it is safe to conduct online transactions by turning the address bar green on next generation browsers.
*Code signing certificates (used to sign application installers.)
*Personal certificates (used to sign email.)
*WildCard SSL: Secures the domain and unlimited sub-domains of that domain (example: *.department.cornell.edu). We strongly discourage the use of wildcard certs for most cases. The reasons can be found at https://www.it.cornell.edu/cms/services/ssl/faq-test.cfm#310-291

All certificates are available in 1, 2, or 3 year terms.

For more details about each certificate type, see the Frequently Asked Questions page https://www.it.cornell.edu/cms/services/ssl/faq-test.cfm.

====How to Request a Certificate====

Use the SSL Certificate Request Form for:
*Single domain certificates
*Multiple domain certificates
*Unified communications certificates

For the other certificate types, escalate to L2.

===Service Pages and Documentation===
[http://it.cornell.edu/services/ssl Service documentation] 
[https://ssl.cit.cornell.edu/sslReq/request.html Request for service form] 
[https://cert-manager.com/customer/InCommon InCommon certificate admin site (LEVEL 2 ONLY)] 
[https://www.incommon.org/cert/ General information of InCommon certificate service]

===Support Levels & Response Times===

The IT Service Desk will provide Level 1 and Level 2 support for SSL Certificates.

The target response times for requests for service are defined as follows:
* '''New certificate request''': 1 business day or less.
* '''Emergency certificate request''': 2 hours.
**The only time a certificate request is an emergency is if the customer's site is down until they get a new certificate.
* '''Cornell SSL Request site is down''': 2 hours.
* '''Comodo (vendor) site is down''': Cornell does not have capability to fix issues with the vendor site.

For more information about escalation, please see [[#Escalation|Escalation]].

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

==General Service Questions==
The IT Service Desk Level 1 support can provide answers to the following questions about this service.

[https://www.it.cornell.edu/cms/services/ssl/faq-test.cfm#310-295 Can I get a certificate for a host in a non-Cornell domain?] 
[https://www.it.cornell.edu/cms/services/ssl/faq-test.cfm#310-300 Can I request a code signing certificate?] (Yes. The customer is directed to contact the IT Service Desk. If you receive a request, escalate to [[#Escalation|Level 2]]
We do not renew code signing certificates. We need to add a new one using cornell.edu domain only.) 
[https://www.it.cornell.edu/cms/services/ssl/faq-test.cfm#310-294 What are Extended Validation Certificates?] 
[https://www.it.cornell.edu/cms/services/ssl/faq-test.cfm#310-293 What is a Unified Communications Certificate? ] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm What is a multi-domain SSL certificate? ] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm What is a wildcard certificate? ] 
My server was compromised, my passphrase was lost or compromised, or my private key was lost or compromised. Contact the Identity Management support team to revoke the certificate. See [[#Escalation|Escalation]].

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

==Supported Tasks and Activities==
Request an SSL Certificate: User should go to ssl.cit.cornell.edu and fill out the form. 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm Generate a Certificate Signing Request (CSR) file in Microsoft IIS 6.0 without removing the existing certificate.] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm Generate a Certificate Signing Request (CSR) in Linux using Open SSL.] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm Generate a Certificate Signing Request (CSR) for apache/linux/openssl.] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm Create a certificate signing request for other platforms.] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm Install my certificate on Apache with mod_ssl.] 
[https://support.comodo.com/index.php?/Knowledgebase/List/Index/37/certificate-installation Install my certificate on some other platform.] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm Verify the SSL installation.] 
[https://www.it.cornell.edu/services/ssl/faq-test.cfm Renew my certificate.] 
[https://www.it.cornell.edu/cms/services/ssl/faq-test.cfm#306-313 See list of my certificates.] 
How do I download a new certificate?

Answer: The customer should have received an email similar to the one below. There are a lot of links there. Most customers will be using the Apache/Linux platform and therefore they will want the first two links in RED. They need to download both their new certificate as well as the intermediate and root certificate files. Also please refer them to the instructions for installation in the FAQ titled: [https://www.it.cornell.edu/services/ssl/faq-test.cfm#312-308 How do I request an SSL Certificate?]

From: Certificate Services Manager <support@cert-manager.com>
Subject: Enrollment Successful - Your SSL certificate for sample.cit.cornell.edu is ready
Date: June 17, 2014 1:14:30 PM EDT
To:

Hello,
You have successfully enrolled for a SSL certificate.
You now need to complete the following steps:

Click the following link to download your SSL certificate (generally try to use a version that includes intermediates & root - or your certificate may be rejected by some older clients)
Format(s) most suitable for your server software:
as X509 Certificate only, Base64 encoded: https://cert-manager.com/customer/InCommon/ssl?action=download&sslId=xxxx&format=x509CO
as X509 Intermediates/root only, Base64 encoded: https://cert-manager.com/customer/InCommon/ssl?action=download&sslId=xxxx&format=x509IO
as X509 Intermediates/root only Reverse, Base64 encoded: https://cert-manager.com/customer/InCommon/ssl?action=download&sslId=xxxxx&format=x509IOR

Other available formats:
as PKCS#7 Base64 encoded: https://cert-manager.com/customer/InCommon/ssl?action=download&sslId=xxxx&format=base64
as PKCS#7 Bin encoded: https://cert-manager.com/customer/InCommon/ssl?action=download&sslId=xxxxx&format=bin
as X509, Base64 encoded: https://cert-manager.com/customer/InCommon/ssl?action=download&sslId=xxxx&format=x509
Import your new certificate into your server (Instruction: https://support.comodo.com/index.php?_m=knowledgebase&_a=view&parentcategoryid=88&pcid=1&nav=0,96,1).
Your renew id: Rb4raYwJsvlpuE7p-K6T
Certificate Details:
Common Name : sample.cit.cornell.edu
Subject Alternative Names :
Number of licenses :
SSL Type : InCommon SSL
Term : 3 Year(s)
Server : Apache/ModSSL
Requested : 06/17/2014 15:54:19 GMT
Approved : 06/17/2014 17:04:34 GMT
Expires : 06/16/2017 23:59:59 GMT
Order Number : 14679408
Self-Enrollment Certificate ID : 331189
Comments : dab66''

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

==Troubleshooting==

===Cannot sign in to the ssl.cit.cornell.edu site to request a certificate. ===
User must have the cu.employee permit to request a certificate. Escalate to L2 to check their permits, see [[#Escalation|Escalation]].

===Certificate Request Failed===

If the user receives an email similar to the one below:

# Ask if Cornell owns this domain. If yes, escalate to [[#Escalation|Level 2]].
# If not, inform the user that we can't issue the certificate for this domain. The user may want to request that the domain be created as a Cornell-owned domain following these instructions: http://www.it.cornell.edu/services/netreg/howto/domain/index.cfm

'''Cornell University SSL Certificate Request'''
Your SSL certificate request failed
You are not authorised to order for this common name: test.info.org

===Problem Connecting to https://ssl.cit.cornell.edu/sslReq/===
User can't connect to https://ssl.cit.cornell.edu/sslReq/
*To determine if the issue is with the site or an issue for this customer, try the URL: https://ssl.cit.cornell.edu/sslReq/
**If the SSL site is down, escalate to [[#Escalation|Level 2]].
**If the customer can't connect to the site, have them try connecting to Who I Am: https://www.whoiam.cornell.edu
**If the customer can't connect to Who I am, the problem is not a widespread outage for the SSL Certificate site. escalate to [[#Escalation|Level 2]].

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

==(Level 2 Only) Supported Tasks and Activities==

Level 2 Support at the IT Service Desk provides support for the following tasks and activities:

===Approve SSL Certificate===

When user submits a SSL request from the Cornell SSL request self-service site at https://ssl.cit.cornell.edu/sslReq/request.html, a confirmation email is sent to sslcert-admin@cornell.edu.

The email resembles the following:

An SSL certificate for helpdesk.cs.cornell.edu has been requested by cfs@cs.cornell.edu and is awaiting approval at https://cert-manager.com/customer/InCommon

Certificate Details:
Common Name : helpdesk.cs.cornell.edu
Subject Alternative Names :
Number of licenses :
SSL Type : InCommon SSL
Term : 3 Year(s)
Server : Microsoft IIS 5.x and later
Requested : 06/27/2011 13:21:39 GMT
Approved :
Expires :
Order Number :
Self-Enrollment Certificate ID : 24202
Comments : jjs87

Where the email address associated with the cert is an EGA or otherwise a shared address, the '''Comments''' field contains the NetID of the requester. This is supplied from the CUWebAuth authentication, not typed by the customer, so it can be relied on.

'''To approve'''

1. If the request is for a domain ending in qatar-med.cornell.edu or qatar-weill.cornell.edu: Check to see if the requester is in the cit.idm.sslcert permit, and if so you can approve the request. If the requester is not in this permit, escalate to L3. (For other domains, proceed to step 2.)

2. If the request is for a non-cornell.edu domain, check this confluence page https://confluence.cornell.edu/display/sslcert/Domains to see if the domain is listed, and verify that the requester of the certificate is the admin of the domain. If the requester is the admin of the domain, you can approve the request. Otherwise, forward the SSL request confirmation email to the domain admin and ask for approval of the request.

3. Verify that the requester is allowed to request the SSL certificate for the requested domain. There are several ways to verify the requester. Try steps a through d, and if you can't determine whether the person is authorized, go to step 4.

: a. Use http://dnsdb.cit.cornell.edu/dnsdb-cgi/netadmin.cgi to search for the subnet administrators associated with the 3-part domain, so if the cert request is for xxx.admissions.cornell.edu, you're looking for the subnet administrator for ''admissions.cornell.edu.'' Be sure to look for ALL the administrators of the domain - for example, library.cornell.edu has many admins listed.

: b. For serverfarm machines, the owners/administrators are in sfinfo: http://sfinfo.cit.cornell.edu

: c. If the contact email address is web-services@cornell.edu it is ok to approve the request.

: d. Also requests from JP's group [need to add more info here.]

4. If you have tried steps a-d, and cannot determine if the user is authorized, then you will need to email the admin of the 3 part domain. First check to see that the admin for the domain is still a Cornell employee via HelpHero. If the admin is no longer at Cornell, make a note of this and escalate to sslcert-admin (L3). Otherwise, forward the SSL request confirmation email to the administrator(s) and ask for approval of the request.

As long as the requester is admin of the domain or approved by the admin of the domain, we approve the request. (InCommon offers unlimited certs at one fixed rate, so we don't care if the user has requested the cert for this domain before.)
*Log on to https://cert-manager.com/customer/InCommon, find the certificate in the list of certificates, click the radio button, next to the certificate, and click the "Approve" button.
*Close (not resolve) the Remedy ticket. (No message goes to the user.)
*You will receive an email that the certificate has been generated. You can ignore this email as it also is sent to the requester of the certificate.

===Customer Requested a Certificate, But Has Not Received It===

Check the Comodo website to see if the request exists.
#Log on to https://cert-manager.com/customer/InCommon
#If it shows up in the "Applied" status, that means the certificate has not been issued. It should be issued within a few hours. If the user has not waited for a few hours, then ask them to check back in 2 hours.
#If the certificate is in status "Issued", then you can click on details and then use the "Resend" button. Notify the customer that you have asked for the certificate to be resent and to contact you if they don't get it within an hour.
#If the certificate doesn't exist, ask customer to resubmit the certificate request using the ssl.cit.cornell.edu site.
#If the customer is still having issues, open a case with Comodo. Go to https://support.comodo.com/. (Level 2 staff with Comodo user IDs need to register with Comodo first before submitting a case. This can be done on the Comodo site, and only needs to be done once.) Use department of "Certificates".

===User is requesting a Code Signing Certificate===
*Log on to https://cert-manager.com/customer/InCommon
*Click the Code Signing Certificates Tab
*Click the Add button and fill out the form
*Notify the user that you've made the request, they will get an email about the code signing cert and they should follow the instructions in the email.
*Resolve the ticket.

===User is requesting a SHA-1 certificate===

Starting on Sep 23, 2014, the user interface at ssl.cit.cornell.edu will default to allowing users to request only SHA-2 certificates. However, there may be a case where a user needs a SHA-1 certificate because their platform does not support SHA-2, and they can send us a request for that.

*(SHA-1 certificates are only good for one year, no way to change that.)

*The user will need to send us:
** the domain name (aka Common Name)
** the CSR
** their server platform (apache, IIS, etc)
** the email or EGA address that should get notifications about this certificate.

*Once you have all this information, log on to [https://cert-manager.com/customer/InCommon the InCommon Certificate Manager]
* select the "Certificates" tab
* click on the "Add" button
* fill in the form as follows:
**Organization: Cornell University (default)
**Department: Certificate Management (default)
**Type: select either "InCommon SSL" or "InCommon Multidomain SSL". (Certificate types are SHA-1 unless they say otherwise.)
**Certificate Term: 1 year (default)
**Server Software: based on what the customer specified, usually "Apache/ModSSL" or "Microsoft IIS 5.x and later"
**CSR: cut and paste (or upload) the CSR that the customer sent to us. Remember to include the "Begin Certificate" and "End Certificate" lines.
**Common Name: the domain name
**Requester: Your name
**External Requester: Email address of the customer, or an EGA that they specified.
**Comments: (you can leave this blank)
*Click on the "OK" button.

*Once you have entered the request, you will have to go through the normal approval process, with all the checks to see if the user is allowed to request a certificate for this domain, etc.

===L2 Support person is having trouble with the Comodo site===
#Open a case with Comodo. Go to https://support.comodo.com/. Level 2 staff with Comodo user IDs need to register with Comodo first before submitting a case. This can be done on the Comodo site, and only needs to be done once.) Use department of "Certificate Manager". Attach a screen shot.

===Wildcard Certs===

We are not in general allowing customers to request wildcard certs. We do allow renewals, but those must be done directly by the Identity Management administrator. Escalate to [[#Escalation|Level 3]].

===Multidomain Cert expiration too short===
Multidomain certs which contain a qualified domain name AND either an unqualified domain (can't look it up with nslookup) or an IP address are being deprecated. Therefore, certificates for these will be issued with a shorter expiration time. The fix for this is to tell people to get a self signed cert for their unqualified domain name and configure that separately in Apache, and use a Comodo multi domain cert for their regular URLs. [https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/722/0/acceptable-internal-domain-names Link to explanation from Comodo]

===New Domain Registration===

*Customers can order a certificate for a non-Cornell domain (one that doesn't end in "cornell.edu", for example, "birds.org")
*As long as Cornell owns the domain, customers can order the cert for it.
*Check that the domain has been registered. You can do this using [http://www.whois.com whois]. Enter the domain name in the top right box labeled "Whois Lookup".
**If the domain is not registered, email the customer that first they need to register the domain with any internet domain provider (GoDaddy, etc.)
**If the domain is registered, check the registration information to be sure it lists someone at Cornell as the contact person. This is the information that InCommon will be checking as well. If Cornell is not listed, email the customer and ask them to update their Whois record so that it contains a Cornell University contact.
*Now, once they have registered their domain properly so that Whois.com finds it, before they can place the order, we need to add the domain to our domain list on the Comodo site.

#Log on to https://cert-manager.com/customer/InCommon
#Make sure SSL certificates tab is highlighted.
#Select '''Settings''', click '''Domains''', and then click '''Add'''.
#In the pop-up windows, enter the ''Domain name''. Please enter domainName and *.domainName. For example, if the new domain name is wilson.org, click the add button and enter "wilson.org". Finish the step 5, then click the "Add" button again and add the "*.wilson.org" domain.
#Also open the "+" next to "Cornell University". Check the boxes for BOTH "Cornell University" and also "Certificate Management", and the "SSL" and "Code Signing" Boxes. Uncheck the Smime boxes.
*Next, the ticket must be moved over to the Identity Management queue. Enter a note in the ticket that informs the IDM team that you have added the two domains via the cert manager site. Once Identity Management has acted on the ticket, you should watch for an email to come back saying that the domain has been approved, then continue with the next step.
*After InCommon approves the domain, you should start the domain validation process (DCV) from InCommon admin interface. The email validation method is the easiest way to do DCV.
#Find out what are the available email addresses from the DCV drop down list. Only use the email address method if it is associated with a person, i.e. it looks like a NetID. (Don't use the email method if the email address is for an EGA).
#If there is not a good email address available, then use the HTTP validation method. You will have to download a file, and ask the requester to put this file on their site. Once they have placed the file on their site, you must go back to do the test on the Comodo DCV validation site.
#Now the Comodo domain site should list this domain as validated. Then you can notify the user that they can go ahead and request their certificate at the ssl.cit.cornell.edu site.
#Once the new domain passes the DCV, it is valid for a year. After one year, we have to do the DCV process again. For domains belonging to either the web-services group or to Academic Technologies, we should do the renewal. For other domains, see the instructions on the [https://confluence.cornell.edu/display/ossm/Processing+DCV+Validation+Expiration+Notices Level 2 Confluence page].

InCommon documentation http://www.incommon.org/certificates/repository/index.html

===Domain Validation Expiration===
[https://confluence.cornell.edu/display/ossm/Processing+DCV+Validation+Expiration+Notices Processing Domain Validation Expirations (Level 2 Confluence page)]

===Code Signing Certificate===

When a user requests a code signing certificate, we need to trigger an invitation to the user.

#Logon to https://cert-manager.com/customer/InCommon
#Click ''''Code Signing Certificate''''.
#Click '''Add''', and then choose ''cornell.edu'' as the domain.
#Fill out the rest of the form. An invitation email will be automatically sent to the user.
#Notify the user that you have requested the code signing certificate and that they should get an email from InCommon within 1 business day. They should follow the directions in the email.

===User would like a list of certificates that have been issued in the past===
We can do this through the Comodo interface, but the Service Desk can only see certificates issued since about July 14, 2014. If the user wants a list of certificates issued before that, ask them for a list of NetIDs and EGAs that would be associated with the certificates, then escalate the case to Identity Management with a note that we cannot see the older certificates.

For a list of certificates issued since July 14, 2014 or later, go to the [https://cert-manager.com/customer/InCommon Comodo website].
*Reports tab
**Reports: SSL Certificates
**Current status: Issued
**From: Select date
**To: Select date
**Organization/Department: Cornell University
**Click on the run button. A CSV file will be sent to you containing ALL SSL certificates issued between the specified dates.
*Load the CSV file into Excel and delete out the certificates that were assigned to other customers.
*Save the CSV file and send it to the user.

==(Level 2 Only) Troubleshooting==

===Problem: Error when trying to approve the certificate: Unable to enroll certificate for Local Domain/Private IP for term more than 1 year===
This could be caused by a typo in either the dns name or one of the SAN (alternative) names on the request. Go to the Certificate approval site, https://cert-manager.com/customer/InCommon, select the certificate and click on the details button. If there is a typo, for example "cornell.eud" instead of "cornell.edu", that could be the cause of the problem. Check for typos in both the "Common Name" and "Alternative Names". If there is a typo, "Revoke" the request and ask the customer to create a new CSR (without the typo) and resubmit the request to the ssl.cit.cornell.edu site.
===Problem: The customer cannot sign in to the ssl.cit.cornell.edu site to request a certificate. ===
User must have the cu.employee permit to request a certificate. If the user is an affiliate, escalate to L3. If the user is a student, they should find a person who is a staff member to request their certificate.

===Problem: The customer cannot connect to https://ssl.cit.cornell.edu/sslReq/request.html===

'''Answer:''' See if Level 2 can connect to https://ssl.cit.cornell.edu/sslReq/request.html. If not, escalate to [[#Escalation|Level 3]]. If yes, see next question.

===Problem: Level 2 can connect to https://ssl.cit.cornell.edu/sslReq/request.html but customer cannot===

'''Answer:''' Have customer try to connect to whoiam.cornell.edu. If customer cannot connect to whoiam, troubleshoot things like customer's netid/password until they can connect to whoiam.cornell.edu. Then have customer try https://ssl.cit.cornell.edu/sslReq/request.html again. If it still doesn't work, escalate to [[#Escalation|Level 3]].

===Problem: The SSL request form does not complete after it is submitted. (just hangs)===

'''Answer:''' The Comodo site might be down. See if you (not the customer) can access this url: https://cert-manager.com/customer/InCommon

*'''If yes''', you can access https://cert-manager.com/customer/InCommon: Check the remedy queue in about 10 minutes to see if the request for the ssl certificate ever came in from the customer. It might have been submitted to Comodo even if the form did not indicate a completed request. If the ssl cert request does not come into Remedy, then ask the customer to try resubmitting the form, an hour or two from when they first tried the request.

*'''If no''', you cannot access https://cert-manager.com/customer/InCommon, escalate to [[#Escalation|Level 3]].

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

==Ticket Casing==
For manually created or edited tickets (from phone calls or emails) case as defined below.

For all SSL Certificate Requests, set
*Service = Identity Management
*OpCat:
**Tier 1 = Request
**Tier 2 = Service
**Tier 3 = Create
*Product = SSL Server Certificate
Request the following information from the customer
*NetID 
'Note:' Requests for SSL Certificates should be submitted via the form at: https://ssl.cit.cornell.edu/sslReq/request.html. Using this form will email a case into Remedy in the Service Desk (L2) support group and apply the correct casing information as described above.

==Escalation==

===Widespread Outage Affecting Many Customers===
If you determine the problem is with the site and affecting multiple customers, contact:
*[mailto:hy93@cornell.edu Hong Ye] or (607) 255-2630
If Hong is unavailable, contact:
*[mailto:pb10@cornell.edu Pete Bosanko] or (607) 254-8683

===Outage Affecting One Customer===
If you determine the problem exists with the customer’s Internet connection and is not a widespread outage, transfer the call or incident to Service Desk Level 2. Reassign the incident to the '''Cornell University IT, CIT Support, Service Desk (L2)''' queue.

===From Service Desk Level 1 ===
* Service Outage
** Notify Service Desk Level 2 of the outage. Reassign the incident to the Service Desk (L2) queue.
* Problem reported by one user and not a widespread outage
** Escalate to Service Desk Level 2 for additional troubleshooting.
* If all Level 1 support options are exhausted, escalate to Service Desk Level 2

* Other known escalations to L2
** User is requesting a code signing certificate.
** User is requesting a SHA-1 certificate.
** User has not received certificate after 1 business day.
** User has an emergency situation and needs certificate in a hurry.
** User made a mistake when requesting the certificate.
** User is requesting a wildcard certificate.
** User wants a client certificate for their email.

===From Service Desk Level 2 ===
*Known escalations to sslcert-admin (L3) queue:
** User wants a wildcard certificate
** Certificate is not working when installed
** User wants a client certificate (for email)
** New domain registrations (see instructions above)
** User wants a list of certificates issued to them including those before about July 14, 2014.

===Information to Include when Escalating an Incident===
When escalating an incident, include the following information in the Remedy incident:
* Name and NetID of the caller
* Phone number of the caller
* Type of certificate being requested (Single domain, multi domain, code-signing, etc)
* Domain name for the website (or URL) if this is for a website certificate
* A description of the problem

===Escalation Status Follow-Up===
The general process is to:
* Look up the ticket in Remedy to see the updated work detail records entered by the person assigned to the incident.
* Make a work info note in the incident documenting the customer inquiry as to the status of their escalated request.
* If no work info records exist regarding the escalated work on the incident, contact the person assigned to the incident.

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

==Service Ownership==

SSL Certificates is a service of Cornell Information Technologies.

*Service Owner: [mailto:se10@cornell.edu Steve Edgar], se10@cornell.edu, 255-0019
*Service Manager: [mailto:wm63@cornell.edu Wyman Miles], wm63@cornell.edu, 255-8421

<center>---'''[[#ToC|Go back to the Table of Contents]]'''---</center>

[[Category:Supported]]

Space shortcuts

Page tree