You can start a business small. For example, organize the resale of domains and SSL certificates. You find customers for existing sellers and get rewarded in the form of discounts and margins - in other words, become a reseller. You can quickly set up reselling domains and SSL certificates using software ISPsystem.

Important! We recommend starting not with the technical implementation, but with the business model and the legal side of the issue. Determine the target audience and ways to attract it, develop a pricing policy that is beneficial for you and your customers. Learn the legal and accounting framework. Only after that proceed to the technical implementation of the plan.

What you need to get started

To become a reseller of domains and SSL certificates, you will need:

1. virtual server(VPS/VDS),
2. agreement with sellers of domains and SSL certificates,
3. agreement with payment system,
4. billing platform for receiving payments,
5. site for the sale of services.

Installing and configuring software

To resell domains and SSL certificates, you will need to install BILLmanager on a rented virtual server.

Integration with domain and SSL vendors

To set up the integration, use the data from the domain and SSL vendors you have an agreement with. Typically, the integration requires an API access URL, a reseller code, and an API authorization key. Data may vary depending on the company.

After that, in BILLmanager in the menu Integration - Service Processors you will be able to set up a resale.

You can also start reselling SSL certificates through ISPsystem. You will not need to negotiate with the registrar directly. To do this, in the “Service Processors” section, select BILLmanager 5 and enter your personal account details my.ispsystem.com.

Connection of payment systems

To allow customers to pay for services, set up payment methods. BILLmanager contains more than 30 modules payment: Yandex.Money, WebMoney, PayMaster, Qiwi, PayPal, Bank transfer and others .

To work with a certain payment system, you and your customers must have an account or an account in this system. So choose the most popular Services. To set up the integration, you will need data from the payment system: wallet number and secret key.

Clients will transfer funds from their account to yours. The receipt of funds will be reflected in your account and customer account in BILLmanager.

To accept payments from individuals, you can connect simple electronic systems like Yandex.Checkout or WebMoney. Legal entities pay for services by bank transfer according to the invoice, so to work with them, connect the payment method Bank transfer (Russian bank). Enter your organization's banking details. Connection to payment systems.

Setting up document templates

BILLmanager has pre-installed document templates: invoices, work completion certificates, reconciliation certificates, service contracts, annexes to the contract. Edit them according to your terms of service.

To comply with legal requirements, create and publish on your site Privacy Policy And Terms of Use. Add a link to these documents in the menu Settings - Brand settings - Copyright. When drawing up a personal data processing policy, follow the recommendations of Roskomnadzor. Setting up document and message templates

Setting up mail and message templates

BILLmanager contains over 60 email templates. Clients will receive letters when registering, ordering services, invoicing. Billing will notify you when the service expires. You can also customize templates for SMS messages and mass mailings. In the panel, you can change the type of messages.

Setting up integration with the site

Website integration

To sell services, information about them must be placed in open access. If you have a website, set up the display of services on it. Prepare images and tariff descriptions and generate a link to a specific one in BILLmanager tariff plan with the desired payment period. When clicking on the link, the user will immediately be taken to the purchase page of the selected product. Configuring BILLmanager integration with the site

Cards of goods and services

You can quickly place tariffs on the site using the Showcase tool. The tool allows you to add a card of one or more services to the site so that the user can select the one and order. The prices in the cards are updated automatically.

To add a card, you need to place a special script in the place where you want to display it. You can find the script in the documentation: Integrating a storefront into an existing site.

Branding

Going from your site to Personal Area in BILLmanager, customers may feel a discrepancy: the site and billing are designed differently, the billing address contains the server's IP address and is different from the site address.

To “level up” the styles, complete the brand settings: add your logo to the billing, change the color of the interface, publish links to the site. To ensure that the billing URL does not differ from the website, configure the address for BILLmanager . For example, CloudLite has a website address cloudlite.ru, billing address - myvdc.cloudlite.ru.

Good news in November 2016 for our dear customers and site users. Our online store does not stand still, regularly updating not only the range of product offers, but also expanding the functionality of the site, its security for users and significance in the global Internet system. So, on September 26, 2016, the online store site received an SSL certificate with extended verification, and from November 1, 2016, after testing and improving the algorithms of work, we connected payment systems to the site!

Now let's take a closer look at the need for these actions and what advantages do our precious customers get from this?

The main visual advantage that every client can notice is the ability to pay ONLINE bank card any order from our online store and take it to a convenient address. As for the internal, hidden advantage of site updates - an SSL certificate is a special way to encrypt a site between global network The Internet, the browser and the user of the site, in other words, the fact that the site is now protected from the possibility of attacks and the seizure of your payment (and even contact) information by third parties. For getting SSL certificate our site had to pass a check of the real existence of the organization, confirmation of receipt and binding of the certificate to the domain and integration new system a secure site to a familiar online store site. From now on, users of our site can be completely confident in the safety of using our convenient and modern site, make purchases and not be afraid of leaking their data to third parties.

By the way, we also do not stand still in expanding the possibilities of receiving our orders, and since the fall of 2016 we have begun to offer our customers the opportunity to receive orders with new delivery methods - by the SDEK courier service and through inPost parcel terminals. Both services are present in many large cities of Russia, the cost of their services is very democratic, and the speed of work sometimes amazes even lovers of expensive and high-quality courier services! We advise you to try new shipping methods, it will save you time and money, and give you a pleasant experience of receiving goods.

Our online store site is a modern, dynamically developing company, offering our customers the most modern and safe ways payment and receipt of our orders. Stay tuned for updates that are coming to be grandiose and global, both in expanding the range and in providing more opportunities to our precious customers !!

Protection against external attacks

divides the client, and, if the client has the necessary rights, provides him with access to the system). If such a check gives an error, the request is rejected. Validation of the client key identifier occurs on each request, which eliminates the forgery of requests and / or responses.

Since the client (Internet browser) and client BS-Defender can function physically separately (on different computers), the BS-Defender's settings provide for restricting access to it ( "Only from this computer"- default,

"Only allowed nodes from the list" or "No restrictions"). Through one

BS-Defender can work simultaneously with several banks or with one bank, but under different logins (requires additional settings).

The possibility of logging (logging) of both all traffic and separately failed requests is provided.

6.2.2. Authentication when working with two-way

To determine a specific client, the RTS application server that serves the sub-

Internet Client system, guided client key identifier (so-called UID). As a rule, one of the properties of the certificate is used as the UID in the system (for example, its serial number). Having received from web servers information about the client certificate contained in the header of the client https request, RTS determines the UID of the client connecting to the system. To do this, RTS looks up the certificate in the system's client certificate store and retrieves the UID from it.

To be able to work with the Internet Client subsystem, the following condition is necessary: ​​UID must be registered in the database with which the application server works. Upon receipt of a request, the application server determines whether the received UID is in the database, and, based on the results of the check, starts (or does not start) servicing requests from this client. If the UID is not found, an error message will be generated for any request on behalf of this client and transmitted to the client.

The situation with two identical UIDs is impossible - the bank has a restriction on the impossibility of using more than one certificate (public key) with the same UID. Thus, personal identification of requests sent by the client is achieved.

6.2.3. Authentication when working with one-way SSL (password and cryptographic)

In the case of using one-way SSL, the connection to the server is protected only by bank personal keys registered only on the WEB server.

Thus, any user, even those who do not have the right to work with the Internet Client subsystem, can connect to the WEB server. To ensure the legitimacy of entering the client workstation of the Internet-Client subsystem, authentication using a password is mandatory. As an optional authentication method, the CIPF key authentication mode (“cryptographic authentication”) can be enabled.

Protection against external attacks

When accessing an SSL site on a client in the status bar of the window Internet Explorer appears

lock symbol. By double-clicking on this symbol, you can view information about the server certificate. Thus, in addition to automatic server authentication, visual server authentication is possible when establishing a secure session.

6.2.3.1. Password authentication

To enter the Internet-Client subsystem, a "login-password" pair is used.

The login and password are assigned at the time of generating the distribution kit of the AWP client of the Internet-Client subsystem. When generating, the password is present only on paper (printed on the specified printer, a special printer can be used to print the password value inside a closed envelope), only the result of the HASH function from the password is stored in the bank's database. Thus, the secrecy of the assigned password is achieved - all operations with the password are carried out only between the obtained results of the HASH functions and the stored values ​​of the HASH functions.

Login is also a client identifier, on the basis of which a session is opened on the RTS server.

When entering the Internet-Client subsystem, in response to the requirement to enter a login and password, the client will have to enter the values ​​received with the distribution kit. If the password is entered incorrectly three times (the number is insisted), it is considered compromised, and Account blocked. To unblock, the client needs to contact the branch of the Bank that issued the distribution kit of the Internet-Client subsystem.

After entering the Internet Client subsystem, the password can be reassigned (changed) by the user himself. In this case, the password in the bank's database is also not stored in the clear, but the result of the HASH function from the new password is saved.

Additional requirements may apply to user passwords: minimum password length, password expiration date, and so on. The use of simple passwords may also be prohibited (see Section 4.8.1.2.3.4 Ensuring Identity Verification

kov users" doc.Complete Guide user).

To provide additional protection system from unauthorized access, it is possible to check the user's identification characteristics. Internal and external IP address are used as user identification features. network interface and/or MAC addresses network cards installed in the user's workstations (see Section 4.8.1.2.3.4 "Ensuring User Identity Verification" doc.). Addresses are transferred to the system server when a connection is established.

6.2.3.2. Cryptographic authentication

To the existing authentication by "login-password", the so-called "Authentication by CIPF keys" can be included. At the time of generation of the Internet Client distribution kit, the client is always given a set of personal cryptographic keys to ensure legal confirmation of the authenticity and reliability of electronic payment documents sent to the bank. Accordingly, when entering the InternetClient subsystem, the same keys can also be used for authentication.

Protection against external attacks

Consider the sequence of operations for cryptographic authentication:

1. After passing the password authentication, the server generates a specific and unique connection for the current session for this user data sequence.

2. This sequence is stored in the session cache on the banking side; a blocking flag is set, which prohibits the opening of the session until the server receives the signature of this data block from the client.

3. The sequence is passed to the client side.

4. Client from the list of possible crypto-profiles (signatures) selects and signs the received sequence with the selected one.

5. The signature, without the signed sequence, is sent to the bank.

6. On the banking side, a unique sequence is restored from the session cache.

7. The received signature is verified under the restored sequence.

8. If the signature is correct, then the blocking flag is removed and the session "In- ternet client.

9. If the signature is not correct, an error message is generated, and return to pp. 4.

6.2.4. Using session keys when working with a subsystem Internet - Client

In addition to authentication of users of the "Internet-Client" subsystem using passwords, it is possible to use user authentication by session keys generated in the "RBS BS-Client" system or using the eToken PASS hardware device (see section 4.8.2.1.1 "Generation of sets session keys in the system "RBS BS-Client" doc. Complete user manual). When using this mechanism, the user gets full access to the subsystem only after entering the key requested by the system. If the key has not been entered, the user receives limited access to the subsystem, without the ability to perform cryptographic operations on documents.

6.2.5. Using session keys when working with the Phone - Client subsystem

To be able to work with personal data (receiving information on accounts, making payments, etc.), the client must be authorized in the Phone-Client (TC) subsystem. As a set of authorization data, the so-called

my “kit”, consisting of a PIN code and set of session keys(KSK).

Both the PIN-code and the SC are a set of numbers, the length of which is in the range from 3 to 10 characters (set by the administrator during generation).

Protection against external attacks

The PIN-code is unique within the "RBS BS-Client" system.

SC is used to increase the level of security when accessing data through the PhoneClient.

SC may be unique either within a separate set, or within the system as a whole, or not be unique at all. SC can be both disposable and reusable.

The client phone has a flexible mechanism for setting the security policy:

limiting the validity of a set of SCs;

the possibility of single or multiple use of SC;

word length of PIN-code and SC;

various types of uniqueness of the SC;

the possibility of replacing both the “envelope” as a whole and its individual components (PIN code, SK);

formation of documents based on personal templates.

6.3. Filtering user requests in a subsystem Internet - Client by IP and MAC

As an additional means of protection against external attacks, the Internet Client subsystem can use filtering of user requests:

on internal and external IP addresses of the network interface;

MAC addresses of network cards installed in user workstations.

For each subsystem user, a list of allowed IP and MAC addresses can be specified from which a connection can be made to the subsystem site (see section 4.8.1.2.3.4 “Ensuring User Identity Verification”, doc. Complete user manual).

Setting up payment systems

Setting up payment systems largely depends on how the payment system operator itself provides communication with its terminals. As a rule, if city payment terminals are used, then a secure SSL connection is used and you need to enable and configure the SSL WEB server to communicate with the terminals as shown below. If websites on the Internet are used for making payments, then how often in such cases it is necessary to configure the http server for Carbon Billing. Be sure to first check with your payment system operator on which communication protocol it provides connection to its payment terminals before setting up Carbon Billing.
The SSL WEB server for payments has several parameters, the meanings of which are described below.

Enable SSL WEB server for payments- If the payment system operator works with payment terminals via SSL, then it is necessary to enable the SSL WEB server.
IP address for HTTPS connection- address for connecting terminals or sites of payment systems for making a payment to a client in the Carbon Billing database.
Port for HTTPS connection- port 1443 is used by default. If there is a need to change this port, then, if possible, specify ports higher than 1024.
Allowed client addresses for SSL WEB server
Domain for server SSL certificate- specify here your public domain or domain registered separately for the payment server on Carbon Billing. The option is optional and allows you to access the SSL WEB server via domain name instead of an IP address.
Require and verify a client certificate- Be sure to check if you are setting up the cashier web interface. If you are setting up work with the payment system, then check the need to verify the client certificate with the payment system operator.
Create client certificate- A client certificate will be created, which will need to be provided to the payment system operator. The certificate with the .pfx suffix will be available on the server in the /var/lib/usrcert directory and will have a filename equal to the CN name you specified when creating the certificate. You can download the certificate file from the server using the winscp program.

In case of setting up an HTTP WEB server for payments.

Enable HTTP server for payments- If the payment system operator works with payment terminals via an open http connection, then enable the HTTP server.
IP address for HTTP connection- Web server address for connecting terminals or payment servers to it.
HTTP connection port- port 1444 is used by default. If there is a need to change this port, then, if possible, specify ports higher than 1024.
Allowed Client Addresses for HTTP Server- if not specified, then access will be open to everyone.

If you use the services of payment system operators listed below on this tab, then enable the menu items corresponding to them. In the future, these checkboxes will set specific system settings required for each of the operators you use. If your operator is not one of those listed below, then do not include any of them.

When setting up the Robokassa payment system, do not forget to specify the secret password required to establish a connection between the terminal and the server.

Criticality of the subjectAltName parameter of ssl certificates

When generating ssl certificates for a server, for example, for an https payment server, the subjectAltName extension is used. Historically, by default, this extension in the certificate is marked as critical, which can lead to problems when integrating billing with some payment systems.

When generating client certificates, subjectAltName is not set.

The criticality of the parameter is canceled by the option in the local console "Configuring the server - Additional settings- Developer options - Don't make SSL parameter AltName critical".

After enabling this option, all newly generated server certificates will be generated with a non-critical subjectAltName extension. The old certificate for the https payment server will have to be manually regenerated as follows:

1. Remount the partition containing the config to rw (remote assistant mode must be enabled for this):

Mount -o rw,remount /mnt/bk_disc/

2. Open the /etc/ics/ics.conf file with an editor and comment the line with MHTTPD_F_CERT .

3. Restart the https payment server:

/etc/init.d/mhttpd_F restart

Changing the certificate at the https payment server does not affect the previously generated client certificates for cashiers or payment systems.

Setting up acceptance of payments via http without encryption

If it is necessary to accept payments from payment systems using the insecure http protocol, the following settings must be made:

1) Enable http server to receive payments.

2) Specify the IP address on which requests should be received. This address must belong to one of the Carbon Billing interfaces:

Then specify the port on which the server will receive requests.

3) Make a list of IP addresses from which requests will be accepted. This is very important step since http does not imply authorization of the payment system through a certificate:

By default, protocols of the payment system Robokassa and Unikassa can work with HTTP. If it is necessary, for example, to accept requests for http using the OSMP protocol, then you need to do the following:

1) Load the server in ud. assistant and connect via ssh as root.

2) Run the following commands:

Mount -o rw,remount /mnt/ro_disc chattr -i -R /var /www/fiscal/htdocs/http/ cp /var /www/fiscal/htdocs/osmp.php /var /www/fiscal/htdocs/http/ osmp.php chown mhttpd_F:mhttpd_F /var /www/fiscal/htdocs/http/osmp.php

You need to edit the line in the script:

Mcedit /var /www/fiscal/htdocs/http/osmp.php line: include "../include/class_page.php"; replace with: include "../../include/class_page.php";

Save the file and exit the editor.

After a soft reboot, the OSMP payment acceptance module will be available at http://1.1.1.1:1444/osmp.php from IP address 2.2.2.2.

Access with a negative balance

Can be implemented in two ways:

• Through the editor of rules and tariff networks;
• Across [additional settings file ics_tune.sh]

SSL version 3.0 was the basis for TLS protocol(Transport Layer Security), which differs from SSL in minor details. In what follows, the term SSL will refer to both protocols.

10.1. Data exchange in SSL

The process of data exchange using the SSL protocol is shown in fig. 10.1.

Whenever a client connects to a server, an SSL session is started. Multiple connections are possible within each session. If the client connects to another server, a new session is started without breaking the current one. When returning to the first server, the user can either resume the connection using the previously set parameters or create a new connection. To prevent attacks, SSL involves a session time limit (usually 24 hours), after which the session is terminated, and a new session must be created in order to continue communicating with the server.

An SSL session is characterized by the following values.

• Session ID (Session_ID) - random number, which is generated on the client side and allows you to return to an already established session.
• Host certificates (Client_Certificate and Server_Certificate) - certificate of the participant of information exchange in accordance with the ISO/IEC 9594-8 standard.
• Compression method - an algorithm for compressing transmitted data. Supported algorithms are specified in RFC 3749.
• Cipher specification - defines the parameters of crypto algorithms:
  • for key exchange and authentication: RSA public key cryptosystem, Diffie-Hellman shared secret key generation protocol, DSA (Digital Signature Algorithm), Fortezza.
  • for symmetric encryption: RC2, RC4, DES, 3DES, IDEA, AES;
  • for hashing: SHA, MD5.
• The session secret key (Master_Secret) is the secret key shared between the client and the server.
• Resume flag - a parameter that determines whether the selected parameters can be saved for a new connection within the current session.
• An SSL connection is characterized by the following values.
• Random numbers (Client_Random and Server_Random) used to generate the shared secret.
• Keys for encrypting/decrypting information (Client_Write_Secret = Server_Read_Secret and Server_Write_Secret = Client_Read_Secret).
• Keys for signing messages (secret Server_MAC_Write_Secret and Client_MAC_Write_Secret).
• Initialization vectors (Server_IV and Client_IV) - sync messages for block encryption algorithms.
• Two consecutive numbers for the server and client to prevent interception and replay attacks.

10.2. SSL protocols

SSL includes four protocols, which are shown in Fig. 10.2 :

• handshake;
• record;
• alert;
• CCS (Change Cipher Specification).

Rice. 10.2.

handshake. This protocol is intended for mutual authentication of a client and a server, establishing a session or connection.

The session setup, shown schematically in Fig. 10.3 is typically initialized by the client with a ClientHello message (sometimes the server initiates it by sending a HelloRequest message indicating that the server is ready for a Handshake), in which the client passes the following parameters:

• version of SSL supported by the client;
• session identifier - a value by which the session can be resumed later;
• random number Client_Random;
• list of algorithms for compression, encryption and hashing of information supported by the client.

In response to this message, the server sends a ServerHello message containing the following parameters:

• version of SSL supported by the server;
• random number Server_Random;
• a list of algorithms for compressing, encrypting and hashing information that will be used when implementing a session or connections.

In addition to this message, the server sends its own certificate. In the event that the algorithms used require a client certificate, the server sends a certificate request to the client - CertificateRequest. The server then sends a ServerHelloDone message to the client, indicating the end of the ServerHello message.

If the client does not support the algorithms proposed by the server, or does not send its certificate in response to the appropriate request, then the session establishment is aborted. Otherwise, the client verifies the server's certificate, generates a Pre_Master_Secret, encrypts it with the server's public key derived from the server's certificate, and sends the resulting value in a ClientKeyExchange message. The server decrypts the received message with its private key and extracts the Pre_Master_Secret. Thus, both sides (client and server) have three values ​​- Server_Random, Client_Random and Pre_Master_Secret and can work out Master_Secret according to the scheme shown in fig. 10.4.

After that, both parties send a Finished message, which is the session parameters encrypted on the secret key Master_Secret and symbolizes the completion of the process of establishing a new session.

The connection establishment is completed by sending ChangeCipherSpec messages by the client and the server, confirming the acceptance by both sides of the algorithms for compressing, encrypting and hashing information and Finished messages, symbolizing the completion of the process of establishing a new connection.

record. This protocol is designed to convert data transmitted by the session layer to the transport layer and vice versa. Data conversion occurs according to the scheme shown in Fig. 10.7.

The information transmitted by the sender is divided into blocks no larger than 2^14 + 2048 bytes each. Each block is then compressed using the selected compression algorithm. After that, the MAC of each block is calculated and attached to the last one. The received fragments are sequentially numbered to prevent attacks, encrypted using the selected algorithm and transmitted to transport layer. The recipient decrypts the received fragments, checks the sequence of their numbers and the integrity of the messages. The fragments are then unpacked and combined into a single message.

CSS. The CSS protocol consists of a single message allowing the Record protocol to perform data transformation using selected algorithms.

Alert. This protocol generates error messages that occur during the transfer of data or the establishment of a session or connection. Depending on the nature of the errors, a warning will be issued or the connection/session will be terminated. Examples of errors are given in Table. 10.2.

10.3. Using SSL in payment systems

Most electronic payment systems, in particular online stores, use web browsers in their work. Considering that SSL is built into almost all known web browsers, the security of transmitted data in 99% of cases [ 3GPP TR 21.905: Vocabulary for 3GPP Specifications.] is based on it. However, the following should be noted negative sides SSL , which must be taken into account when deciding whether to use this protocol when organizing a secure channel for interaction between participants in electronic payment transactions.

• Lack of buyer authentication. Despite the fact that the SSL protocol has the ability to request a buyer's certificate, buyer authentication is optional and, as a rule, is not carried out, which makes it impossible to use SSL when transactions with a bank account.
• Authentication of the seller by URL. The certificate provided by the seller only indicates the connection of the latter with the specified URL, while there is no information about the interaction between the seller and the bank serving the specified payment system.
• Openness of the details of the buyer. Despite the fact that all information transmitted under SSL is encrypted, the buyer's bank details are sent to the seller in the clear.
• Export restrictions of the protocol. Despite the fact that in 1999 the US State Department decided to remove export restrictions, some browsers support SSL protocol with export restrictions regarding the length of keys for information encryption algorithms, which significantly reduces the security of transmitted data.